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Abstract 

A hybrid system is one in which digital components and analog components inter- 
act. Typical examples of hybrid systems are real-time process-control systems such 
as automated factories or automated transportation systems, in which the digital 
components monitor and control continuous physical processes in the analog compo- 
nents. The computer science community has developed formal models and methods 
for reasoning about digital systems, while the control theory community has done 
the same for analog systems. However, systems that combine both types of activity 
appear to require new methods. The development and application of such methods 
is an active area of current research. 

One of the formal tools that has been developed is the hybrid I/O automaton 
(HIOA) model [1]. In this case study, we show how this model can be used to spec- 
ify and verify part of an automated transportation system — a vehicle deceleration 
maneuver. We investigate how techniques such as automata composition, invariant 
assertions, and simulation mappings can be applied to systems of communicating dig- 
ital and analog components. The purpose of the case study is to test the applicability 
of these computer science based techniques to the area of automated transit. In par- 
ticular, we are concerned that HIOA techniques express hybrid systems faithfully and 
that they allow clear and scalable proofs of significant properties of these systems. 

In the deceleration maneuver, digital controller slows a train to a target velocity 
range within a given distance. We examine four versions of the deceleration maneuver, 
each with a different model of the communication between controller and train: plain, 
delay, feedback, and feedback with delay. For each case we give a model of the non- 
controller portion of the system, define correctness of a controller, give an example of 
a correct controller, and prove that it is correct. This case study contains full proofs 
of the correctness of the various controllers. However, some of the proofs are only 
sketched, when similar formal proofs appear in other chapters. 
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Chapter 1 



Introduction 



A hybrid system is one in which digital components and analog components inter- 
act. Typical examples of hybrid systems are real-time process-control systems such 
as automated factories or automated transportation systems, in which the digital 
components monitor and control continuous physical processes in the analog compo- 
nents. The computer science community has developed formal models and methods 
for reasoning about digital systems, while the control theory community has done 
the same for analog systems. However, systems that combine both types of activity 
appear to require new methods. The development and application of such methods 
is an active area of current research. 

One of the formal tools that has been developed is the hybrid I/O automaton 
model [1]. In this case study, we show how this model can be used to specify and 
verify part of an automated transportation system — a vehicle deceleration maneuver. 
We investigate how techniques such as automata composition, invariant assertions, 
and simulation mappings can be applied to systems of communicating digital and 
analog components. The purpose of the case study is to test the applicability of these 
computer science based techniques to the area of automated transit. In particular, 
we are concerned that HIOA techniques express hybrid systems faithfully and that 
they allow clear and scalable proofs of significant properties of these systems. 

Formal Framework 

The hybrid I/O automaton model is an extension of the timed I/O automaton model 
of [2, 3, 4, 5] inspired by the phase transition system model of [6] and the similar 
hybrid system model of [7]. A hybrid I/O automaton (HIOA) is a (possibly) infinite 
state labeled transition system. The states of a HIOA are the valuations of a set of 
variables. Certain states are distinguished as start states. The transitions of a HIOA 
are of two types: continuous and discrete. A HIOA's discrete transitions are labeled 
with actions. Both the variables and the actions of a HIOA are partitioned into three 
categories: input, output, and internal. A hybrid execution of a HIOA is a sequence of 
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transitions that describes a possible behavior of the system over time. A hybrid trace 
of a HIOA is the externally visible part of an execution (i.e. the non-internal part). 

We say that one HIOA implements a second, more abstract HIOA if the traces 
of the hrst are included in those of the second. This captures the notion that the 
implementation HIOA has no external behavior that isn't allowed by the specification 
HIOA. When two HIOAs are composed in parallel, they synchronize on shared in- 
put/output actions and shared input/output variables. Under certain easily checked 
conditions, the parallel composition of two HIOAs is itself a HIOA. An important 
property of HIOA's is substituitivity: in a system composed of HIOAs, substituting 
implementations of the components yields an implementation of the entire system. 

As has been the case in previous work with timed I/O automata, most of the 
proofs in this HIOA based case study use invariant assertions and simulations. An 
assertion is a predicate on states; an invariant assertion is one that is true in every 
reachable state. Invariant assertions are usually proved by induction on the length 
of an execution. A simulation is a mapping between states of two HIOA that can 
be used to show that that one HIOA implements another. The proof that a given 
mapping is a simulation is another form of induction on the length of an execution 
of the implementation; the induction matches individual steps in the implementation 
with corresponding steps or sequences of steps in the specification. Even proofs of 
timing properties can be performed using these techniques; the key idea is to build 
timing information into the state where it can be tested by assertions. 

This type of formalism has several benefits. First, the inductive structure and styl- 
ized nature of the proofs makes them easy to write, check, and understand. In some 
cases, this structure has allowed the proofs to be checked using automated theorem 
proving techniques. Second, the implementation relation allows the description of a 
system at different levels of abstraction. Assertions proved on the high level models 
extend to the lower level models via the simulation mapping. This hierarchy helps 
manage the complexity of the overall specification and it helps simplify the proofs 
because assertions are usually easier to prove on the more abstract models. Third and 
finally, the methods are not completely automatic. They require the user to supply 
invariants and simulations, which serve as useful documentation of the system. In an 
exploratory work such as this case study, the insight gained through a manual process 
is particularly useful because it may lead to developments in the underlying models 
and methods. 

The Deceleration Maneuver 

Typical examples of automated transportation systems include the Raytheon Per- 
sonal Rapid Transit System and the California PATH project [8, 9, 10]. In these 
hybrid systems, a number of computer controlled vehicles share a network of tracks 
or highways. The digital part of the system is the computer vehicle controller and the 
analog part of the system is the vehicle, its engine, the guideway, and so forth. In [8] 



the control of the transportation system is described hierarchically. The higher levels 
of such a hierarchical system coordinate and determine strategy while the lowest level 
performs specific maneuvers. 

This case study focuses on a single maneuver: the task of decelerating a vehicle 
to a target speed within a certain distance. Such a maneuver might be invoked, for 
example, when a vehicle is approaching an area whose maximum allowable velocity 
is lower than the vehicle's current velocity. We model a vehicle and its controller as 
two communicating HIOAs. We do not model the invocation of the maneuver nor do 
we investigate either complex vehicle physics or complex control schemes. Instead we 
have considered four variations on the communication between vehicle and controller. 
The four variations arise from the inclusion or exclusion of two parameters: feedback 
and delay. The hrst case is the simplest: no feedback and no delay. The second 
case introduces a communication delay between the controller and the vehicle. The 
third case introduces feedback without delay; the vehicle periodically sends sensory 
information to the controller. The fourth case involves both feedback and delay. For 
each case, we give a formal specification of what it means for a controller to correctly 
implement the deceleration maneuver, then we give an example implementation of 
such a controller and formally verify that it correctly implements the maneuver. 

Related Work 

This case study is part of a long-term project in the M.I.T. Theory of Distributed 
Systems research group on modeling, verifying, and analyzing problems arising in 
automated transit systems. A survey of the project appears in [11]. The case study, 
[12, 13], examines the train and gate problem from traditional railroad control. In 
[14], the author uses abstraction to relate continuous and discrete control of a vehicle 
maneuver. Safety systems for automated transit are examined in [15]. 

The development of models and verification methods for timing-based systems is 
an active research area within computer science. The timed I/O automaton model 
is similar, for example, to a model of Alur and Dill [16], to one of Lamport [17] 
and to one of Henzinger, Manna and Pnueli [18]. In contrast to those formalisms, the 
development and use of the timed I/O automaton model has focused on compositional 
properties [19], implementation relations [20], and semi-automated proof checking [21] 
with less emphasis on syntactic forms, temporal logics, and fully automatic analysis. 
Just as timed I/O automata have been extended to hybrid I/O automata to treat 
hybrid systems, so have other real-time models. For example, the timed transition 
system model of [18] is extended to the phase transition system model in [6]. Phase 
transition systems are analogous to hybrid I/O automata: their transitions correspond 
to our discrete steps; their activities correspond to our trajectories. The hybrid system 
model of [7] is similar to the phase transition system model except that it includes 
synchronization labels that correspond to our actions. This allows a notion of parallel 
composition in the hybrid system model. The hybrid system model differs from the 



HIOA model because it has no input/output distinction on either labels (actions) or 
variables. 

The methods of invariant assertions, abstraction mappings, forward and backward 
simulations, history and prophecy variables are used in many places in computer 
science. We will not attempt to attribute all these notions. An overview of these 
methods, for untimed and timed systems, appears in [22, 2, 3]. 

Roy Johnson and Steve Spielman at Raytheon are leading the design and develop- 
ment of a prototype advanced personal rapid transit system, based partly on concepts 
developed by Dr. Edward Anderson of the Taxi2000 Corp. Prof. Shankar Sastry and 
his colleagues at Berkeley have studied intelligent highway systems [8, 9, 10] and spe- 
cific scenarios that arise therein. For example, they have considered equipping cars 
with "smart" cruise controls that can adapt to other cars in the vicinity [9]. Another 
project involving formal modeling of train control systems, using some computer sci- 
ence techniques, was carried out by Schneider and co-workers [23]. Their emphasis 
was on the use of an extension of Dijkstra's weakest-precondition calculus to derive 
correct solutions. Other case studies in modeling hybrid systems include two analy- 
ses of steam boiler controllers — one using timed I/O automaton methods [24] and 
another using the automated proof checker PVS [25] — and a project using a variety 
of techniques to model and verify controllers for aircraft landing gear [26] . 

Outline 

In Chapter 2 we give a complete but terse treatment of the HIOA model and the 
notational conventions used in this case study. In Chapters 3, 4, 5, and 6, we present 
a succession of different variations on the deceleration maneuver: no delay and no 
feedback in Chapter 3; delay and no feedback in Chapter 4; feedback and no delay in 
Chapter 5; and both feedback and delay in Chapter 6. We conclude in Chapter 7. 



Chapter 2 

Model: Hybrid I/O Automata 



The hybrid I/O automaton model [1] is based on the timed I/O automaton model 
of [2, 3, 4, 5], but includes more explicit treatment of continuous behavior. To make 
this report self contained, this chapter gives a complete but terse treatment of the 
HIOA model with an emphasis on those aspects used in subsequent chapters. The 
presentation is based on [1] and [27]. 

The chapter is organized as follows. We begin by introducing the notion of a 
trajectory; trajectories are functions that represent the continuous evolution of state. 
We proceed to define hybrid I/O automata (HIOA) and their executions and traces. 
Next, we define a simulation relation between a pair of HIOAs and the operations 
of composition and of action and variable hiding. We conclude by presenting two 
notational forms for automata: standard and MMT-specihcations. 

2.1 Trajectories 

Throughout this chapter, we hx a time axis T, which is a subgroup of (R,+), the 
real numbers with addition. In subsequent chapters we use T = R exclusively, but 
the model permits T = Z and the degenerated time axis T = {0}. An interval 7 is a 
convex subset of T. We denote intervals as usual: [ti,t 2 ] = {t £ T | t\ < t < t 2 }, etc. 
For 7 an interval and t £ T, we define 7 + t = {f + t \ t' £ 7}. 

We assume a universal set V of variables. Variables in V are typed, where the 
type of a variable, such as reals, integers, etc., indicates the domain over which the 
variable ranges. Let Z C V. A valuation of Z is a mapping that associates to each 
variable of Z a value in its domain. We write Z for the set of valuations of Z . Often, 
valuations will be referred to as states. 

A trajectory over Z is a mapping w : 7 — > Z, where 7 is a left-closed interval of 
T with left endpoint equal to 0. With dom(w) we denote the domain of w and with 
trajs(Z) the collection of all trajectories over Z. We say w is an 7-trajectory if it is 
a trajectory with domain 7. If w is a trajectory then w.ltime, the limit time of w, is 
the supremum of dom(w). Similarly, define w.fstate, the first state of w, to be w(0), 
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and if dom(w) is right-closed, define w.lstate, the last state of w, to be w(w.ltime). 
A trajectory with domain [0, 0] is called a point trajectory. If s is a state then define 
p(s) to be the point trajectory that maps to s. 

For w a trajectory and t £ T-°, we define w < t = w \ [0, t] and w <\ t = w \ [0, t). 
(Here [ denotes the restriction of a function to a subset of its domain.) Note that 
w < is not a trajectory. By convention, w<oo = w<ioo = w. Similarly we define, 
for w a trajectory and 7 a left-closed interval with minimal element /, the restriction 
u; f 7 to be the function with domain (7 D dom(w)) — I given by w I 7 (7) = wit + /). 
Note that w I 7 is a trajectory iff / £ dom(w). 

If w is a trajectory over Z and Z' C Z, then the projection w J, Z' is the trajectory 
over Z' with domain dom(w) defined by w J, Z' (£)(z) = u;(i)(z). The projection 
operation is extended to sets of trajectories by pointwise extension. Also, if w is a 
trajectory over Z and z £ Z, then the projection w I z is the function from dom(w) 
to the domain of z dehned by u; J, z (i) = u;(t)(z). 

If u; is a trajectory with a right-closed domain 7 = [0,u], u;' is a trajectory with 
domain 7', and if w.lstate = w' ./state , then we define the concatenation w ^ w' to be 
the trajectory with domain 7 U (7' + u) given by 

w ~w'(t) = { w{t) if * G J : 

[ w'(t — u) otherwise. 

We extend the concatenation operator to a countable sequence of trajectories: if W{ 
is a trajectory with domain 7 8 -, 1 < i < oo, where all 7 8 - are right-closed, and if 
Wi.lstate = Wi + i.fstate for all z, then we define the infinite concatenation, written 
Wi *~ w 2 *~ w 3 . . . } to he the least function w such that wit + J^ • • Wj.ltime) = Wi(t) 
for all t £ 7 8 -. 

A trajectory w is closed if its domain is a (finite) closed interval and full if its 
domain equals T-°. For W a set of trajectories, Closed(W) and 7W/( IF) denote the 
subsets of closed and full trajectories in IF, respectively. Trajectory w is a prefix of 
trajectory u/, notation u; < u/, if either w = w' ov w' = w ^ w" } for some trajectory 
w" . With PrefiW) we denote the prefix-closure of IF: PrefiW) = {w | 3u;' £ IF : 
w < u;'}. Set FF is prefix closed if FF = PrefiW). A trajectory in W is maximal if 
it is not a prefix of any other trajectory in W . We write MaxiW) for the subset of 
maximal trajectories in W . 



2.2 Hybrid I/O Automata 



A hybrid I/O automaton (HIOA) A = (U, A, Y, E m , E mf , E ouf , 0,D, W) consists of 
the following components: 

• Three disjoint sets U, X and Y of variables, called input, internal and output 
variables, respectively. 



Variables in E = U U Y are called external, and variables in 7 = X U Y are 
called locally controlled. We write V = U U 7. 

• Three disjoint sets E m , E mf , E ouf of input, internal and output actions, respec- 
tively. 

We assume that E m contains a special element e, the environment action, which 
represents the occurrence of a discrete transition outside the system that is un- 
observable, except (possibly) through its effect on the input variables. Actions 
in E ea;f = E m U E ouf are called external, and actions in E /oc = E mf U E ouf are 



^loc 



called locally controlled . We write E = E m U E 

• A nonempty set C V of initial states satisfying 

Init (start states closed under change of input variables) 
Vs,s'e V : s G © As\L = s'\L =^ s' G 

• A set PCVxSxVof discrete transitions satisfying 



Dl (input action enabling) 



s" 



Vs G V,aG E m 3s' G V : s ^ s' 

D2 (environment action only affect inputs) 

Vs,s'G Visas' => s\L = s'\L 

D3 (input variable change enabling) 

Vs,s',s" (E\,a(EZ:s^s' As'\L = s"\L =>■ s 

Here we used s — ^-> s' as shorthand for (s, a, s') G T>. 

• A set W of trajectories over V satisfying 

Tl (existence of point trajectories) 
Vs G V : p(s) G W 

T2 (closure under subintervals) 

\/w G W, / left-closed, non-empty subinterval of dom(w): w f 7 G W 

T3 (completeness) 

(Vt G T^° : iw f [0, t] G W) => iw G W 

Axiom Init says that a system has no control over the initial values of its input 
variables: if one valuation is allowed then any other valuation is allowed also. 

Axiom Dl is a slight generalization of the input enabling condition of the (clas- 
sical) I/O automaton model: it says that in each state each input action is enabled, 
including the environment action e. The second axiom D2 says that e cannot change 
locally controlled variables. Axiom D3 expresses that, since input variables are not 
under control of the system, these variables may be changed in an arbitrary way after 



any discrete action. The three axioms together imply the converse of D2, i.e., if two 
states only differ in their input variables then there exists an e transition between 
them. Axioms Dl-3 play a crucial role in our study of parallel composition. In par- 
ticular D2 and D3 are used to avoid cyclic constraints during the interaction of two 
systems. 

Axioms Tl-3 state some natural conditions on the set of trajectories that we need 
to set up our theory: existence of point trajectories, closure under subintervals, and 
the fact that a full trajectory is in W iff all its prefixes are in W. 

Notation Let A be a HIOA as described above. If s £ V and / £ L, then we write 
s — ^-> / iff there exists an s' £ V such that s — ^-> s' and s' \L = I. In the sequel, the 
components of a HIOA A will be denoted by Va, U a-, £U, ©a, etc. Sometimes, the 
components of a HIOA A{ will also be denoted by VJ, £/,-, S 8 -, © 8 , etc. 

2.3 Hybrid Executions 

A hybrid execution fragment of A is a finite or infinite alternating sequence a = 
w aiWia 2 w 2 • • • , where: 

1. Each Wi is a trajectory in Y\)a and each a 8 - is an action in E^. 

2. If a is a finite sequence then it ends with a trajectory. 

3. If Wi is not the last trajectory in a then its domain is a right-closed interval and 
Wi.lstate —^a Wi + i.f state. 

An execution fragment records all the discrete changes that occur in the evolution 
of a system, plus the "continuous" state changes that take place in between. The 
third item says that the discrete actions in a span between successive trajectories. 
We write h-frag(A) for the set of all hybrid execution fragments of A. 

If a = w aiWia 2 w 2 • • • is a hybrid execution fragment then we define the limit 
time of a, notation a.ltime, to be '^ ji Wi.ltime. Further, we define the first state of 
a, a. J "state, to be wq. f state. 

We distinguish several sorts of hybrid execution fragments. A hybrid execution 
fragment a is defined to be 

• an execution if the first state of a is an initial state, 

• finite if a is a finite sequence and the domain of its final trajectory is a right- 
closed interval, 

• admissible if a.ltime = oo, 

• Zeno if a is neither finite nor admissible, and 



• a sentence if a is a finite execution that ends with a point trajectory. 

If a = w aiWi ■ ■ ■ a n w n is a finite hybrid execution fragment then we define the last 
state of a, notation a.lstate, to be w n .lstate. A state of A is defined to be reachable 
if it is the last state of some finite hybrid execution of A. 

A finite hybrid execution fragment a = w aiWia 2 w 2 • • • a n w n and a hybrid execu- 
tion fragment a' = w l a l 1 w l 1 a' 2 w l 2 ■ ■ ■ of A can be concatenated if w n "" w' is defined 
and a trajectory of A. In this case, the concatenation a "" a' is the hybrid execution 
fragment defined by 

a "" a' = w aiWia 2 w 2 • • • a n (w n "" w'^a^w^a^w^ • • • 

A variable v of a HIOA A is called continuous if v is not modified by any discrete 
steps of A and for all trajectories w of A, w J. {v} is a continuous function. Let 
a = w aiWia 2 w 2 ■ ■ ■ be a hybrid execution fragment of A. Then we define a J, {v} as 
follows: 

a I {v} = (w i {v}) ~ (uii | {v}) ~ (w 2 i {v}) . . . 

The following theorem is simple to prove. 

Theorem 2.3.1 If v is a continuous variable of HIOA A and a is an execution 
fragment of A, then a J, {v} is a continuous function. 

2.4 Hybrid Traces 

Suppose a = w aiWia 2 w 2 ■ ■ ■ is a hybrid execution fragment of A. In order to define 
the hybrid trace of a, let 

7 = (w i E A )vis(a 1 )(w 1 J, E A )vis(a 2 )(w 2 | E A ) ■ ■ ■ , 

where, for a an action, vis(a) is defined equal to r if a is an internal action or e, and 
equal to a otherwise. Here r is a special symbol which, as in the theory of process 
algebra, plays the role of the 'generic' invisible action. An occurrence of r in 7 is 
called inert if the final state of the trajectory that precedes the r equals the hrst 
state of the trajectory that follows it (after hiding of the internal variables). The 
hybrid trace of a, written htrace(a) } is defined to be the sequence obtained from 7 by 
removing all inert r's and concatenating the surrounding trajectories. 

The hybrid traces of A are the hybrid traces that arise from all the finite and 
admissible hybrid executions of A. We write h-traces(A) for the set of hybrid traces 
of A. 

HIOA's A\ and A 2 are comparable if they have the same external interface, i.e., 
U 1 = U 2 ,Y 1 =Y 2 , S™ = E™ and E° uf = E° uf . If A t and A 2 are comparable then 
A\ < A 2 is defined to mean that the hybrid traces of A\ are included in those of A 2 : 
A\ < A 2 = h-traces(Ai) C h-traces^Az). If A\ < A 2 then we say that A\ implements 
A 2 . 



2.5 Simulation Relations 

Let A and B be comparable HIOA's. A simulation from A to B is a relation R C 
V^ X Vb satisfying the following conditions, for all states r and s of A and i?, 
respectively: 

1. If r G ©a then there exists s G ©b such that r R s. 

2. If r — ^a f 1 and r R s and both r and s are reachable states then B has a finite 
execution fragment a with s = a. f state, htrace(<p(r) a fp(r')) = htrace(a) and 
r' R a.lstate. 

3. If r R s and w is a closed trajectory of A with r = w.f state and both r and s 
are reachable states then B has a finite execution fragment a with s = a. f state, 
htrace(w) = htrace(a) and w.lstate R a.lstate. 

Note that by Condition 3 and the existence of point trajectories (axiom Tl), r Rs 
and r and s reachable implies that t\Ea = s\Eb- 

Theorem 2.5.1 If A and B are comparable HIOA's and there is a simulation from 
A to B, then A< B. 

The definition of simulation given above is weaker than the one given in [I]. We 
have added the restriction that r and s be reachable states in Conditions 2 and 3. 
Theorem 2.5.1 is true with or without this restriction. 

2.6 Parallel Composition and Hiding 

We say that HIOA's A\ and A 2 are compatible if, for i ^ j , 

Xi n Vj = Y t n Y 3 = £™ f n E, = E 8 0Uf n Ef f = 0. 

If A\ and A 2 are compatible then their composition Ai\\A 2 is defined to be the tuple 

A = (U, A, Y, E m , E mf , E ouf , 0, D, W) given by 

• U = (U 1 U U 2 ) - (Y 1 U y 2 ), A = A x U A 2 , F = F x U Y 2 

• E m = (E™ U E™) - (E°" f U E°" f ), E mf = E™ f U E™ f , E ouf = E°" f U E°" f 

• = {sG V IsfVi G0i As\V 2 G0 2 } 

• Dehne, for i G {1,2}, projection function 7r 8 - : E — > E 8 - by 7r 8 (a) = a if a G E 8 - 
and TTi(a) = e otherwise. Then T> is the subset of V X E X V given by 



• W is the set of trajectories over V given by 

w g w ^=>- iw | v-i e w t a iw | v 2 e w 2 

Notation We extend the projection notation 7r 8 - (i = 1, 2) to states, trajectories and 
hybrid executions in the obvious way. 

Proposition 2.6.1 A 1 \\A 2 is a HIOA. 

Theorem 2.6.2 Suppose Ai,A 2 and B are HIOA's with A\ < A 2 , and each of Ai 
and A 2 is compatible with B. Then A\\\B < A 2 ||i?. 

Two natural hiding operations can be defined on any HIOA A: 

(1) If S C E^ uf , then ActHide(5', A) is the HIOA B that is equal to A except that 

J^out = J^out _ g and E mt = E mt y g_ 

(2) If Z C F A , then VarHide(Z, A) is the HIOA B that is the equal to A except that 
Y B = Y A - Z and A B = X A U Z. 

Theorem 2.6.3 Suppose A and B are HIOA's with A < B, and let S C E^" f ond 

K7 A . 

Then ActHide(5',A) < ActHide(5', 5) aim! VarHide(Z, A) < VarHide(Z, 5). 

2.7 Standard HIOA Notation 

In this section we introduce the notational conventions for defining HIOAs that are 
standard for this case study. An example HIOA called SKEW-TIMER described in 
standard notation appears in Table 2.1. The automaton SKEW-TIMER models a faulty 
count-down timer with an inaccurate clock. The table identifies the actions, variables, 
discrete transitions, and trajectories of SKEW-TIMER. We explain each of these in 
turn. 

• The actions are classified as input, output, and internal. A set of actions may 
be defined by giving an action name with a parameter and a range for the 
parameter. The actions set-timer(x) for x £ IR-° are an example. We say 
"the action set-timer" to mean the set of related actions "set-timer(x) for 

;c£ E^°". 

• The variables are also classified as input, output, and internal. Since there are 
no input variables to SKEW-TIMER, that category does not appear. Variables 
are specified with a name and a type; an initial value is given for internal and 
output variables. 



• The discrete transitions are specified using precondition-effect, Pascal-like code 
as in [28, 29]. Each set of transitions which shares an action label (or set of 
related action labels) is specified as one precondition-effect block. For example, 
the first block describes all set-timer labeled transitions. Because set-timer 
is an input action there is no precondition for this block — in other words, 
the precondition is true (see Axiom Dl). The notation := is the usual Pascal 
assignment notation. The notation :£ is similar but denotes assignment from a 
set. If a variable is not mentioned in the effect clause, then it is unchanged by 
the transition. 

• The trajectories are specified as all the trajectories w that satisfy the given 
set of conditions. The expression w.rate denotes the projection of w onto the 
variable rate. 

Informally, the behavior of SKEW-TIMER is as follows: it has a clock whose rate 
varies non-deterministically between and 2; when it receives a set-timer(x) in- 
put action, it will later output alarm when its clock says that x time has passed; 
however, there may be an internal fault action, which causes the timer to be non- 
deterministically set to any value; the togo output variable reports the time remaining 
until the timer expires. The variable deadline is used to encode the value of clock 
that will trigger the expiration of the timer. 



2.8 MMT Specifications 

The HIOA model is powerful; however, a useful subclass of HIOA can be specified in 
a convenient notation called an MMT-specihcation. The name "MMT" derives from 
the names Merritt, Modugno, and Tuttle, the authors of [30] where they present a 
model which corresponds to this subclass. We prefer to view it as a subclass with a 
particular notation, rather than as a separate formalism. This section is based on a 
similar exposition in [27]. We give a formal definition of an MMT-specihcation, of a 
mapping from an MMT-specihcation to a HIOA, and an example MMT-specihcation 
together with its translation into standard notation. 

An MMT-specification M = (A, T, &/, b u ) consists of the following components: 

• A HIOA A with no external variables and only point trajectories. 

• A task set T which is a collection of disjoint subsets of locally controlled actions 
of A. 

• A lower bound map b\ : T — > IR-°. 

• An upper bound map b u : T — > IR-°. 



Table 2.1 The SKEW-TIMER automaton. 



Actions: Input: set-timer(x) for x G K-° 

Output: alarm 
Internal: fault 
Vars: Output: togo G R-°U {oo}, initially oo 

Internal: clock G IR-°, initially 
rate G [0,2], initially 1 
deadline G IR-° U {oo}, initially oo 

Discrete Transitions: 

set-timer(x): 

Eff: togo := x 

deadline := clock + x 



alarm: 




Pre: 


deadline = clock 


Eff: 


deadline := oo 




togo := oo 


fault: 




Pre: 


togo ^ 


Eff: 


togo :G R-° 




deadline := clock + £ogo 



Trajectories: 

w.rate is an integrable function 
for all t G dom(w) 

wit). deadline = w(0). deadline 

w(t). clock = w(0). clock + J w(s).rate ds 

wit). clock < wit). deadline 

if w(0). deadline = oo then 

wit). togo = oo 
else 

wit). togo = wit). deadline — wit), clock 



The HIOA A specifies the behavior of the automaton which is not related to 
timing; its trajectories are irrelevant so we assume they are point trajectories. The 
remaining elements of the MMT-specihcation define its timing behavior. The tasks 
are sets of actions of A that have related timing behavior; we denote individual tasks 
by C{ where i ranges over an index set. The bound functions specify the timing 
behavior of tasks by giving a lower and upper time bound for the execution of each 
task. We require that for each tasks d G T, bi(Ci) < b u (Ci). An action a is enabled 
in state s when for some s', (s,a,s') is a discrete step of A. A task d is enabled 
in a state if at least one of its actions is enabled. The lower time-bound on a task 
specifies how long the task must be continuously enabled before one of its actions can 
be performed. The upper time-bound on a task specifies how long the task can be 
continuously enabled before one of its actions must be performed. We formalize this 
description by describing the equivalent hybrid I/O automaton. 

Let M = (A, T, &/, b u ) be an MMT-specihcation where and let 

A = (U, A, Y, E m , E mf , E ouf , 0, V, W) 

and V = U U A U Y. By our assumption that M is an MMT-specihcation we know 
that U = Y = and W contains only point trajectories. 

Then A' = hybrid(M) is a hybrid I/O automaton with the following components: 

• The variables of A 1 are the same as those of A plus the following internal vari- 
ables: now of type IR-°; and first(Ci) and last(Ci) of type IR U {oo} for all 
d G T. 

• The actions of A 1 are the same as those of A. 

• The start states A 1 are all the states s of A 1 where s \V G 0, s.now = 0, and for 
each d G T if C{ is enabled in s \V then first(Ci) = bi(Ci) and last(Ci) = b u (Ci); 
otherwise, first(Ci) = and last(Ci) = oo. 

• The discrete steps of A' are all (s, a, s') where: 

1. s' .now = s.now 

2. (s\V,a,s'\V) GD 

3. for each d G T 

(a) If a G Ci, then s.first(Ci) < s.now. 

(b) If d is enabled in both s\V and s'\V } and a (^ C{ } 
then s' .first(Ci) = s.first(Ci) and s'.last(Ci) = s.last(Ci). 

(c) If d is enabled in s'\V and either a G C{ or d is not enabled in s\V, 
then s' .first(Ci) = s' .now + 6/(C 8 ) and s'.last(Ci) = s' .now + b u (Ci). 

(d) If d is not enabled in s'\V then s' .first(Ci) = and s'.last(Ci) = oo. 



• The trajectories of A 1 are exactly those trajectories w where the following hold 
for all t G dom(w): 

1. wit). now = w(0).now + t (now; is a clock variable) 

2. wit) I V = w(0) I V (original variables remain unchanged) 

3. for all d G T 

(a) wit). now < w(0).last(Ci) (time does not pass deadlines) 

(b) w{t).first(Ci) = w(0).first(Ci) (deadlines remain unchanged) 

(c) w(t).last(C'i) = w(0).last(C t ) 

One difference between the exposition here and in [27], is that we do not require 
that the upper bound of a task be non-zero. Such a requirement would guarantee 
certain properties that are required in [27] but that are beyond the scope of this 
exposition. 

A simple example MMT-specihcation PING-PONG appears in Table 2.2; its corre- 
sponding HIOA /jj/&ra/(PING-PONG) appears in Table 2.3 in standard notation. The 
notation PING = {ping} : [3,4], means that task PING consists of the singleton 
set of actions {ping} and has lower and upper time bounds of 3 and 4, respectively. 
Informally, the behavior of PING-PONG is as follows: it alternates performing ping 
and pong output actions; it begins with a ping action after 3 to 4 time units; every 
ping action is followed by a pong action in 7 to 20 time units; every pong action is 
followed by a ping action in 3 to 4 time units. 

In subsequent chapters we ignore the distinction between the MMT-specihcation 
and its corresponding hybrid I/O automaton. When possible, we will use MMT- 
specihcations and not give the corresponding standard notation. However, we will 
refer in proofs to the deadline variables last(-) and first(-). These deadline variables 
have some useful properties: 

Theorem 2.8.1 If M = (A,T,bi,b u ) is an MMT- specification and A' = hybrid(M), 
then in all reachable states s of A 1 and for all d G T the following hold: 

1. s.first(Ci) < s.last(Ci) 

2. s.now < s.last(Ci) 

3. if Ci is enabled in s\V then < last(Ci) — now < b u (Ci) 

The use of deadline variables is key to the assertional proof style. To prove in- 
variant assertions inductively it is often helpful that the entire future behavior of the 
system is determined by the current state. Deadline variables encode future timing 
behavior in the current state. For an example see Lemma 3.6.4. 



Table 2.2 The PING-PONG MMT-specification. 



Actions: Output: ping and pong 
Vars: Internal: count £ N, initially 

Discrete Transitions: 

ping: 

Pre: count is even 

Eff: count := count + 1 

pong: 

Pre: count is odd 

Eff: count := count + 1 

Tasks: 

P/M7= {ping}: [3,4] 
PONG = {pong} : [7, 20] 



Notation All HIOAs that result from MMT-specihcations have the now variable. 
So that we may compose these HIOAs and others that have a similar now variable, we 
adopt a convention for the now variable. We reserve the now identifier only for real- 
valued variables that begin at zero and progress linearly with time at slope exactly 
one — in other words, variables which represent the current time. These variables 
must be internal or output variables. When two automata are composed that both 
have now variables, we implicitly rename the variables to some other unique names 
but refer to both of these variables as if they were named now. 



Table 2.3 The hybrid(pmG-PONG) automaton. 



Actions: Output: ping and pong 
Vars: Internal: count £ N, initially 



now £ E^° 

first(PING) £ R^°U {oo}, initially 3 
last(PING) £ E^° U {oo}, initially 4 
first(PONG) £ E^° U {oo}, initially 
last(PONG) £ E^° U {oo}, initially oo 

Discrete Transitions: 

ping: 

Pre: count is even 

first(PING) < now 
Eff: count := count + 1 

first(PING) := 

last(PING) := oo 

first(PONG) := now + 7 

last(PONG) := now; + 20 
pong: 

Pre: count is odd 

first(PONG) < now 
Eff: count := cown£ + 1 

first(PING) := now; +3 

last(PING) := now; + 4 

first(PONG) := 

last(PONG) := oo 

Trajectories: 

w.first(PING), w.last(PING), w.first(PONG), and 

w.last(PONG) are all constant functions 
for all t £ dom(w) 

wit). now = w(0).now-\- t 

w(t).now < w(t).last(PING) 

w(t).now < w(t).last(PONG) 



Chapter 3 

Deceleration Case 1: 

No Delay and No Feedback 



In the deceleration problem we model a computer-controlled train moving along a 
track. The task of the train's controller is to slow the train within a given distance. 
In this chapter we consider a very simple model of the train and the controller. The 
train has two modes, braking and not braking. The controller can instantly effect a 
change in the mode of the train (relaxed in Chapters 4 and 6). The controller receives 
no information from the train (relaxed in Chapters 5 and 6). The braking strength of 
the train varies nondeterministically within known bounds. We model both the train 
and the controller as hybrid I/O automata. Figure 3-1 illustrates the components 
and their communication. 

In the following sections we describe the parameters of the specification, give a 
hybrid I/O automaton model for the train, define correctness of a controller for this 
train, give an example correct controller, and prove that it is correct. 

3.1 Parameters 

All the parameters of the specification are constants denoted by c with some dots 
above it and a subscript. Dots above the constant identify the type of the constant: 
position (no dots), velocity (one dot), or acceleration (two dots). The dots are a purely 
syntactic device used to express the type of the constant; they do not represent an 
operation of differentiation on some function. The subscript identifies the particular 

Figure 3-1 Overview of Basic Deceleration Model 



TRAIN 



brakeOn, brakeOf f 



A Controller 



33 



constant. Initial values of the train's position, velocity and acceleration are c S} c S} c s . 
The goal of the deceleration maneuver is to slow the train to a velocity in the interval 
[cminf, c max f] at position Cf. When the train is not braking its acceleration is exactly 
zero. When the train is braking its acceleration varies nondeterministically between 
[cmin, c max ] , both negative. The range is intended to model inherent uncertainty in 
brake performance. We impose the following constraints on the parameters: 



1. c s < c f 

Z. Cg s> C max f _ ^minf ^ U 



3. c s 



4. 


c ■ < c < 


5. 


0r r . ^~> maxf » 
-^'--rQax 


6. 


c maxf c s s^ c minf c s 


Cmax c min 



The hrst three constraints are self-explanatory: initial position is before final posi- 
tion; initial velocity is higher than target velocity range which is positive; and initial 
acceleration is zero. Since braking is stronger when acceleration is more negative, 
notice in the fourth constraint that c m i n is the strongest braking strength, and c max 
the weakest. The fifth constraint ensures that with the weakest possible braking there 
is still enough distance to reach the highest allowable speed by position Cf. The right 
hand side of this equation uses a familiar equation for "change in distance for change 
in velocity" from constant acceleration Newtonian physics. To understand the sixth 
constraint consider that since the controller receives no sensory information from the 
train, it must decide a priori how long to brake. The sixth constraint ensures that 
the least amount of time the controller must brake is less than the greatest amount 
of time that it can brake. 

3.2 The TRAIN Automaton 

We model the train as a single HIOA called TRAIN which appears in Table 3.1. The 
notation used in the table is explained in Section 2.7. The train's physical state is 
modeled using three variables: x,x,x. As with the constants, the dots on x and x 
are a syntactic device; the fact there there is a differential relationship between the 
evolution of these variables is a consequence of the definition of the trajectory set 
for TRAIN. The train accepts commands to turn the brake on or off through discrete 
actions brakeOn and brakeOf f . It stores the state of the brake in variable b. While 
braking the train applies an acceleration that is nondeterministic at every point but is 



constrained to be an integrable function with range in the interval [c^n, c max ]. While 
not braking the train has exactly zero acceleration. The variable now represents the 
current time; when using assertions to reason about the timing behavior of systems, 
it is convenient to have an explicit state variable which records the current time. 

Table 3.1 The TRAIN automaton. 



Actions: Input: brakeOn and brakeOff 
Vars: Output: i£R, initially x = c s 

i£R, initially x = c s 
i^R, initially x = c s 
6, a boolean, initially false 
initially 
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Trajectories: 

if w(0).b = true then 

w.x is an integrable function with range [cmi n , c n 
else 

w.x = 
for all t G / the following hold: 

w(t).b = w(0).b 

wit). now = w(0).now-\- t 

w(t).x = w(0).x + J w(s).x ds 

w(t).x = w(0).x + J w(s).x ds 



3.3 Properties of TRAIN 

The following two lemmas and three corollaries all relate the initial state and final 
states of a trajectory. They establish standard facts of mechanics which we prove 
here for completeness. In a treatment of a system with more complex dynamics we 
expect that the lemmas of this section could be replaced with similar results based 



on whatever methods from continuous mathematics were appropriate for the specific 
application. We do not claim that the dynamics of TRAIN are complex or that the 
mathematics used in the proofs in this section is sophisticated. 

In the next two lemmas we characterize the train's behavior when not braking 
and when braking, respectively. Below and throughout this work, if s and s' are 
states and x is a variable, we often write x for s.x and x' for s'.x when s and s' are 
understood. 

Lemma 3.3.1 Let w be a closed trajectory of TRAIN whose initial and final states 
are s and s' , respectively, and let A = now 1 — now. If b = false then the following 
hold: 

1. x 1 = x = 

0) ,-yj * ,-yj 

3. x' = x + xA 
Proof: By the definitions of x and x in TRAIN and integration. I 

Lemma 3.3.2 Let w be a closed trajectory of TRAIN whose initial and final states 
are s and s' , respectively, and let A = now' — now. If b = true then the following 
hold: 

1 . X ~\~ C m j n AA _\ X _\ X ~y~ C max AA 

2. x + xA + |^ min A 2 <x' <x + iA+ |£ max A 2 

Proof: We prove only the right hand side of the two inequalities; the other side is 
symmetric. Let z be a trajectory of TRAIN with the domain I the same as w; and 
let z(t).x = c max for all t £ I and z(0).x = w(0).x and z(0).x = w(0).x. Notice that 
w(t).'x < z(t).'x for all t £ /. Because definite integrals preserve inequalities, we know 
that for all t £ /, w(t).x < z(t).x and w(t).x < z(t).x. Furthermore, by integration, 
we know that z(t).x = w(0).x + c max A. This establishes the hrst inequality. Also by 
integration, we know that z(t).x = w(0).x -\-w(0).xA-\- |c max A 2 . This establishes the 
second inequality. I 

The following corollaries further describe the train's behavior during braking. 
The hrst bounds change in time by change in velocity. The second bounds change in 
position by change in the square of velocity. 

Corollary 3.3.3 Let w be a closed trajectory of TRAIN whose initial and final states 
are s and s' , respectively and let A = now 1 — now. If b = true then the following 
holds: 

< A < 



Proof: We use Lemma 3.3.2. The steps for only one side are shown: 
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Corollary 3.3.4 Let w be a closed trajectory of TRAIN whose initial and final states 
are s and s' , respectively and let A = now 1 — now. If b = true and < x' then the 
following holds: 



'J\2 



x 2 
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< x' — X < 



(i'Y 
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Proof: Again, we show only the right hand side of the inequality. Let A = now 1 — now. 
Let z be a trajectory as in the proof of Lemma 3.3.2 and let / denote the final state 
of z. To make the following algebra easier to read, we let v! = f.x and u' = f.x. As 
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substitution 
distribute 
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as in Lemma 3.3.2 

transitivity 

antecedent 

as in Lemma 3.3.2 
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3.4 Definition of Controller Correctness 



We define a brake- controller to be a hybrid I/O automaton with no external vari- 
ables, no input actions, and output actions brakeOn, and brakeOff. A correct brake- 
controller is one that when composed with TRAIN, yields a HIOA whose hybrid traces 
satisfy the following formal axioms: 



Timeliness There exists a constant t £ IR-° such that for all hybrid traces if there 
exists a state of the trace in which now = t, then there is a state of the trace in 
which x = Cf. 

Safety In all states of all hybrid traces the following holds: 

X Cf ,' C m j n f \ X \ Cmaxf* 

These can be stated informally as: (Timeliness) there is a length of time after which 
we can be sure that the train has reached Cf; and (Safety) when it gets there, it has 
achieved an appropriate speed. The formal definitions of hybrid traces and related 
concepts appear in Chapter 2. Note that in (3.4) the state where x = Cf can occur 
during time passage, i.e. within a trajectory. For convenience we call the hrst property 
the "timeliness" property and the second property the "safety" property. 

A controller which stops time before the system reaches Cf is a correct controller 
according to the above definition. In general, one would like to avoid such vacuous 
correctness results. This issue is beyond the scope of our investigation, but it is 
treated in some depth in [1, 4, 5]. None of the of the example controllers presented 
in this case study stop time. 

The following theorem says that the timeliness and safety properties are preserved 
by the implementation relation (see Section 2.4); in other words, an implementation 
of a correct brake-controller is itself a correct brake-controller. This theorem is not 
used in this chapter but rather in Chapter 4. 

Theorem 3.4.1 Let B be a correct brake- controller and let A < B . Then A is also 
a correct brake- controller. 

Proof: By Theorem 2.6.2, A||TRAIN < i?||TRAIN. Timeliness: Let t be the constant 
which satisfies the timeliness property for B. We show that it also satisfies the 
timeliness property for A. Let a be a trace of A||TRAIN; then a is also a trace of 
i?||TRAIN and the property holds on a by the correctness of B. Safety: Similarly. I 



3.5 Example Controller: ONE-SHOT 

In this section we give an example of a correct brake- controller called ONE-SHOT. 
There is a broad spectrum of correct controllers from which to choose an example — 
from fully deterministic controllers to highly non-deterministic controllers. A fully 
deterministic controller would have exactly one infinite execution (ignoring e tran- 
sitions). We have chosen to present a controller that is highly non-deterministic: 
ONE-SHOT exhibits all the possible timings of exactly one brakeOn action followed by 
exactly one brakeOf f action which a correct controller might exhibit. In other words, 
ONE-SHOT exhibits all the correct braking strategies which involve exactly one appli- 
cation of the brake. We can imagine controllers with more non-determinism which 
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exhibit not only behaviors with single brake applications but also behaviors with mul- 
tiple brake applications. We chose ONE-SHOT as an example for three reasons. First, 
it is easily expressed using an MMT-specihcation. Second, it has enough interesting 
behavior that the proofs of this section illustrate non-trivial proof techniques. Third 
and last, in Chapter 4 we use a simulation proof to show that the composition of 
a similar controller and a delay buffer is an implementation of this controller. The 
correctness of the delayed controller then follows from the correctness of ONE-SHOT. 
First we define some convenient constants: 

A 

B 

C 

^min 

The first, A, is the longest amount of time a correct controller can wait before invoking 
the brake. The others, B and C, are lower and upper bounds, respectively, on the 
amount of time a correct controller should apply the brake if it only brakes once. 
These constants are used as the time bounds on the tasks of ONE-SHOT. 

Table 3.2 The ONE-SHOT automaton (MMT-specihcation) 



Actions: Output: brakeOn and brakeOff 

Vars: Internal: phase £ {idle, braking, done}, initially idle 

Discrete Transitions: 

brakeOn: 

Pre: phase = idle 

Eff: phase := braking 
brakeOff: 

Pre: phase = braking 

Eff: phase := done 



Tasks: ON = {brakeOn} : [0,A] 

OFF = {brakeOff} : [B } C] 



The formal description of ONE-SHOT appears in Table 3.2. The notation used 
in the table, called MMT-specihcation, is explained in Section 2.8. The controller is 
called "one-shot" because it applies the brake only once. The automaton's executions 
consist of three phases idle, braking, and done. It waits between zero and A time 



Figure 3-2 Example Execution of ONE-SHOT-SYS 
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units (idle phase), then it applies the brake for at least B and at most C time units 
(braking phase), and then removes the brake (donephase). The ON task governs 
the transitions from idle to braking and the OFF task governs the transitions from 
braking to done. 



3.6 Correctness of ONE-SHOT 



In this section we prove the correctness of the ONE-SHOT controller. Recall that the 
composition of TRAIN and ONE-SHOT is called ONE-SHOT-SYS. We will present lem- 
mas and corollaries that establish the timeliness and safety properties for the hybrid 
executions of ONE-SHOT-SYS. Before giving the proof, we provide some motivation 
and an overview. 

Figure 3-2 depicts a possible execution of ONE-SHOT-SYS. The vertical axis is 
velocity and the horizontal axis is position. Since the vehicle is always moving forward, 
the graph can be read as if time progresses from left to right. The solid line represents 
the actual behavior of the train in this example execution. The initial flat segment 
corresponds to the idle phase; the downward curve, the braking phase; and the final 
flat segment, the done phase. The shape of the downward curve in this execution 
is meant to reflect a constant deceleration, but this is the exception rather than the 
rule. The train's deceleration can vary nondeterministically during braking as long 
as it remains integrable. As achieved deceleration varies between c m i n and c max the 
curve becomes more or less steep, respectively. 

The dotted lines represent upper and lower bounds that we will prove. The lower 
bound will yield the timeliness property. The meaning of the lower bound is obvious: 
we will show that the controller never allows the speed to fall below the minimum 



final velocity. The upper bound (combined with the lower bound) will yield the 
safety property. The meaning of the upper bound is less obvious: from each point 
on the upper bound, if the controller initiated braking and the train achieved only 
the weakest possible braking (c^x) the train would slow to exactly c max f at the final 
position. Points below this curve are safe because immediately braking for sufficiently 
long will slow the train to strictly less than c max f before the final position. Points above 
this line are unsafe because even with immediate braking, the train may achieve only 
the weakest possible braking — in that case the train will remain strictly above the 
required c max f velocity at the final position. 

Now we proceed to the details of the proof. In the following two sections, we 
prove a variety of properties, almost all of which are invariant assertions. We make 
extensive use of the deadline variables such as last(ON) which are implicit in the 
MMT-specihcation of ONE-SHOT. These variables allow assertions to encode claims 
about timing behavior. The proofs offer an argument for the clarity and simplicity of 
the assertional proof style. Almost all of the proofs involve only very local reasoning 
about steps of the system. The only proof which is not based on an assertion style, 
that of Lemma 3.6.8, relies on Theorem 2.3.1. 

Section 3.6.1 establishes the timeliness property; Section 3.6.2 establishes the 
safety property. Together they yield the correctness of the controller which is sum- 
marized in Theorem 3.6.14. 

3.6.1 Timeliness 

In this section we prove the timeliness property, namely that there is a bound t on the 
time it takes to reach Cf. Our method is to prove that at all times there is a positive 
lower bound on velocity, specifically c m i n f- We do this by characterizing velocity for 
each of the three phases: idle in Lemma 3.6.3, braking in Lemma 3.6.4, and done in 
Lemma 3.6.5. Some of the results are more general than necessary for the timeliness 
property because they will be used in the next section for proving the safety property. 
The following two technical lemmas will be used to eliminate certain cases in later 
inductive arguments. The hrst says that there is only one idle phase and it occurs 
at the beginning of the execution. The second says that there are some dependencies 
among the values of the variables 6, x, and phase. 

Lemma 3.6.1 In all reachable states of ONE-SHOT ; if (phase = idle) then the fol- 
lowing hold: 

1. first(ON) = 

2. last(ON) = A 

Proof: Trivial induction. I 

Lemma 3.6.2 In all reachable states of ONE-SHOT-SYS the following hold: 



1. ? X kz [^min? CmaxJ 

2. -^b^ x = 

3. b <^=> (phase = braking) 

Proof: Trivial induction. I 

The following lemma characterizes the velocity and position of the train during 
the controller's idle phase. 

Lemma 3.6.3 In all reachable states of ONE-SHOT-SYS, if phase = idle the follow- 
ing hold: 

1. x = c s 

2. x = c s + (now)c s 

Proof: By induction. The interesting case is trajectories where we note that x = 
and Lemma 3.3.1 applies. Some trivial algebra yields the desired result. I 

The following lemma characterizes the velocity of the train during braking. It is 
interesting because it involves assertion-style reasoning about the controller's deadline 
variables. While the controller is in the braking phase, last( OFF) — now is the greatest 
amount of time the train will continue braking. This time must be bounded in order 
to avoid slowing down below the minimum final speed, c m i n f- A similar result holds 
for first( OFF) and the upper bound on velocity. 

Lemma 3.6.4 In all reachable states of ONE-SHOT-SYS, if phase = braking the 
following hold: 

1. last(OFF) - now < ^i^i 

v ' — c m ; n 

2. first(OFF) - now > c ^^ f ~ x 



L-max 



Proof: By induction. The two interesting cases are the ON task that sets phase = 
braking and trajectories while phase = braking. For the CWtask the pre-state has 
phase = idle and Lemma 3.6.3 and the definitions of B and C yield the desired 
results as follows (only (2) is shown): 

B _ c maxf-c s b definition 

Cmax J 

x = c s = x' by Lemma 3.6.3 

first{OFF)' = now' + B one-shot definition 

first{ OFF)' - now 1 = c ^~ x substitute k subtract 

For trajectories, we use Lemma 3.6.2 and the equation from Corollary 3.3.3. Sub- 
traction and expansion of A = now 1 — now yields the desired results as follows (only 



IS s 



hown): 



now — now 
first(OFF) — now 
first(OFF)- now 1 



/ X —X 

Cmax 
\ c maxf & 

_ c max 
\ c maxf & 



by Corollary 3.3.3. 
inductive hypothesis 
substitute and cancel 



The following corollary uses basic properties of deadline variables and the preced- 
ing lemma to prove that as we exit the braking phase and thereafter, we are in the 
target velocity range. 

Corollary 3.6.5 In all reachable states of ONE-SHOT-SYS, if phase = done the fol- 
lowing holds: 

^maxf _ ^ _ C m i n f 

Proof: By induction. The interesting cases are the OFF action and trajectories in 
the done phase. For the OFF action we know that in the pre-state phase = braking 
so Lemma 3.6.4 applies. Furthermore first( OFF) < now < last(OFF) by a property 
of MMT automata. From this we can conclude that c maxt > x > c m i nt (details for one 
side shown below). For trajectories, we know that x = so x = i', by Lemma 3.6.2 
and Lemma 3.3.1. 



first{ OFF) - now > Cm ^ xf ~' 
first(OFF) < now" 
first(OFF)- now < 
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from Lemma 3.6.4 

from Theorem 2.8.1 

subtraction 

transitivity 

assumption 

multiply 

subtract 



The following lemma and associated corollary combines the above phase-by-phase 
results to yield the global result and the time bound. 

Lemma 3.6.6 In all reachable states of ONE-SHOT-SYS the following holds: 

% _ C m i n f 

Proof: We consider cases of phase. When phase = idle Lemma 3.6.3 gives x = c s 
and by assumption c s > c max f > c m inf- When phase = braking, Lemma 2.8.1 gives 
now < last(OFF) and Lemma 3.6.4 gives the desired result. Finally when phase = 
done, Corollary 3.6.5 applies. I 



Corollary 3.6.7 In all reachable states of ONE-SHOT-SYS the following holds: 

x > c s + c mini (now) 

Proof: Lemma 3.6.6 establishes that in all reachable states (including those in trajec- 
tories) x > c m inf. At all times x — c s is the integral of x. It is a property of definite in- 
tegrals that lower bounds are preserved. Therefore x — c s > J c m infdt = c m i n f(now). 

■ 

The following lemma establishes the timeliness property. 

Lemma 3.6.8 Let a be a trace of ONE-SHOT-SYS. // there exists a state s of a in 
which s.now = c !~ c ° , then there is a state s' of a in which s'.x = s'.Cf. 

c minf 

Proof: By Corollary 3.6.7 we know that in state s, s.x > Cf. We observe that no 
discrete action modifies x and that for all trajectories w of the system, w.x is a 
continuous function. Therefore x is a continuous variable of ONE-SHOT-SYS (see end 
of Section 2.3). Let a' be an execution of ONE-SHOT-SYS whose trace is a. Let 
f = ct' I { x }- By Theorem 2.3.1, / is a continuous function. We know f (s.now) > Cf 
and that /(0) = c s < Cf. By the intermediate value theorem, it follows that for some 
t where < t < s.now, fit) = Cf. We conclude that a state where x = Cf is achieved 
in a' and hence in a. I 



3.6.2 Safety 

In this section we prove the safety property, namely that the following formula is an 
invariant of the system: 

yX Cf '' C m j n f \ X \ CmaxfJ 

We have already shown that at all times cWnf < i, therefore we need only establish 
the other half of the inequality. To prove this invariant we prove a stronger invariant: 



X < Cf ==?■ Cf — X > 



C maxf X 

2c 



Intuitively, this invariant says that before reaching the final position there must be 
enough distance left to brake, even at the weakest braking. It has as a special case 
the safety property (note that c max is negative). This is a common technique for 
proving an invariant: not all invariants can be proven inductively but there is usually 
a strengthening of the invariant which can. Once again, we prove the invariant for 
each phase(3.6.9 } 3.6.10, 3. 6. II) and combine the results (3.6.12). The safety property 
is proved in corollary 3.6.13. 

Lemma 3.6.9 In all reachable states of ONE-SHOT-SYS, if phase = idle then Cf — 

ry ~~^> maxf 

-^'--rQax 



Proof: By Lemmas 2.8.1 and 3.6.1 we know now < A. Using the equations for x 
and x from Lemma 3.6.3 we substitute and simplify, yielding the desired result (see 
definition of A). 
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from now < A 

multiply by c s and add 

c s 

from Lemma 3.6.3 

= and < transitive 

subtract Cf and reverse 
sign 



Lemma 3.6.10 In all reachable states of ONE-SHOT-SYS, if phase = braking then 
Cf — X > 



2 in 



Proof: By induction. The interesting cases are the ON task and trajectories while 
phase = braking. In the ON task case Lemma 3.6.9 applies to the pre-state; since 
none of the state variables mentioned in the formula change during the ON task the 
formula still holds. In the trajectory case, we substitute from Lemma 3.3.4 into the 
inductive hypothesis and simplify. 
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subtract 
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Lemma 3.6.11 In all reachable states of ONE-SHOT-SYS ; if x < Cf and phase = done 
then 



™2 



Cf — x > 



^maxf 



2c n 



Proof: Directly using Lemma 3.6.5. The left hand side is bounded below by zero 
because x < Cf. The right hand side is bounded above by zero because x < c max f. I 



Corollary 3.6.12 In all reachable states of ONE-SHOT-SYS, if x < ci then 

i 2 -i 2 
Cf — X > -^^ 



2 in 



Proof: Directly using Corollaries 3.6.9, 3.6.10, and 3.6.11. I 

Corollary 3.6.13 In all reachable states of ONE-SHOT-SYS; 

Cf X ,' C max f ^ X ^_ C mm f 

Proof: Directly using 3.6.12 and 3.6.6. I 

We conclude this chapter with a theorem which summarizes the correctness result 
for the ONE-SHOT controller. 

Theorem 3.6.14 The following are true of ONE-SHOT-SYS; 

Timeliness For all hybrid traces a of ONE-SHOT-SYS ; if in some state of a now = 
^— —, then for some state in a x = Cf . 

c minf 

Safety In all states of all hybrid traces of ONE-SHOT-SYS ; the following holds: 

X Cf ,' C m j n f \ X \ Cmaxf* 

In other words, ONE-SHOT is a correct brake- controller. 

Proof: We establish the timeliness property for hybrid executions of ONE-SHOT-SYS in 
Lemma 3.6.8; we establish the safety property for hybrid executions of ONE-SHOT-SYS 
in Corollary 3.6.13. The properties extend to the hybrid traces of ONE-SHOT-SYS 
because each hybrid trace is the projection of some hybrid execution. Controller 
correctness is defined in Section 3.4. I 



Chapter 4 

Deceleration Case 2: 
Delay and No Feedback 



In this chapter we extend the model of the train by nondeterministically delaying the 
braking commands. Rather than modify the train automaton itself, we introduce a 
new automaton called BUFFER that will serve as a buffer between the train and a 
controller. Figure 4-1 illustrates the components and their communication. 

In the following sections we present BUFFER, modify the correctness criteria to 
account for the BUFFER, give an example controller called DEL-ONE-SHOT, and prove 
that it is correct. The proof uses a simulation mapping to show that the com- 
position of DEL-ONE-SHOT and BUFFER implements ONE-SHOT; the correctness of 
DEL-ONE-SHOT then follows (in part) from Theorem 3.4.1. 

4.1 The BUFFER Automaton 

The buffer stores a single command from the controller. It forwards it to the train 
after some delay. For each command, the delay is nondeterministically chosen from 
the interval [<5~,<5 + ] (where < 6~ < 6 + ). 

The BUFFER automaton appears in Table 4.1. It is largely self explanatory. The 
variable request stores a command while it is being buffered. The history variable 
violation becomes true when a new command from the controller arrives before the 
previous one has exited the buffer, that is when the buffer overflows. We use violation 

Figure 4-1 Overview of Delay Deceleration Model 
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Table 4.1 The BUFFER automaton. 



Actions: Inputs: buf BrakeOn and buf BrakeOf f 

Outputs: brakeOn and brakeOff 
Vars: Internal: request £ {on, off , none}, initially none 

violation, boolean, initially false 
Discrete Transitions: 
buf BrakeOn: 

Eff: Cases of request, 
on : no effect 
off : violation := true 
none : request := on 
bufBrakeOff: 

Eff: Cases of request, 
on : violation := true 
off : no effect 
none: request := off 
brakeOn: 

Pre: request = on 
Eff: request := none 
brakeOff: 

Pre: request = off 
Eff: request := none 



Tasks: 

BUFF= {brakeOn, brakeOff} : [$~,$ + ] 



to flag this error condition. 



4.2 Definition of Controller Correctness, Revisited 

We modify the definition of a correct controller to account for the buffer. Let <f> be an 
operator on automata which hides the actions buf BrakeOn and bufBrakeOff (see Sec- 
tion 2.6). A correct buff ered-brake- controller is a HIOA C with no external variables 
and with output actions buf BrakeOn and bufBrakeOff such that the composition 
</>(C||BUFFER)||TRAIN is a correct brake- controller as defined in Section 3.4. The use 
of the hiding operator <f> in the correctness definition is a technical convenience. 



4.3 Parameters, Revisited 

Not only do we need to place restrictions on the value of the new parameters (<5~, <5 + ), 
but we also need to revise the constraints among the original parameters in light of 
these new ones. Intuitively, the controller is subject to more uncertainty and therefore 
needs less stringent requirements. The further constraints can be viewed as forcing 
the target velocity range, [c m i n f, c max f] to be wider and hence the controller's task 
easier. These are the additional constraints: 

1. < 6- < 6+ 

^* &s — ^maxf "T C max 
<5* C max f ^_ Cmijrf "T C mm 

c max Cmin 

The hrst constraint ensures that the delay interval is well-defined. The next 
two are necessary to ensure that the buffer does not overflow. The last constraint 
replaces constraint number six in Section 3.1; the new version accounts not only for 
the nondeterminism of the braking strength but also for the buffer. The other five 
original constraints remain as well but are not shown here. Note that these constraints 
in this chapter are more restrictive than the constraints from Chapter 3. 



4.4 Example Controller: DEL-ONE-SHOT 

Here we give an example of a valid buffered-brake-controller called DEL-ONE-SHOT. 
This automaton is identical to ONE-SHOT of Section 3.4 except in the names of its 
actions and the duration of its phases. The output actions brakeOn, brakeOff are 
replaced by buf BrakeOn, buf BrakeOff . The time bounds A, B } C are replaced by 
A', B', C. These new bounds are: 

A'=max(0,A-<5 + ) 
B' =B + S + - 6~ 
C' =C-S+ + 6~ 

We also name the following compositions of automata: 
DEL-ONE-SHOT-AND-BUF = </>(BUFFER| |DEL-ONE-SHOT) 

DEL-ONE-SHOT-SYS = TRAINl IdEL-ONE-SHOT-AND-BUF 



4.5 Correctness of DEL-ONE-SHOT 

The proof of correctness of the controller requires proofs of the timeliness and safety 
properties. First, we prove that the buffer never overflows in Section 4.5.1. In Sec- 
tion 4.5.2 we prove timeliness and safety using a simulation mapping to the unbuffered 
case of Chapter 3. The timeliness and safety results of the unbuffered case extend via 
the simulation to this case. 

4.5.1 Non- Violation 

Non- violation is proved directly. 

Lemma 4.5.1 In all reachable states of DEL-ONE-SHOT-AND-BUF 
the following holds: 

violation = false. 

Proof: Violation occurs when request ^ none and a buf BrakeOn or buf BrakeOff 
action takes place. Since these actions are controlled by the ON and OFF tasks it 
is sufficient to show that first(ON) and first(OFF) are greater than now whenever 
request ^ none. The following invariant of DEL-ONE-SHOT-SYS is sufficient: 

request ^ none => last(BUFF) < mm(first(ON),first(OFF)) 

This follows from a simple inductive argument that uses the new constraints on the 
target velocities and the definition of B' . I 

4.5.2 Timeliness and Safety 

In this section we prove the timeliness and safety properties for DEL-ONE-SHOT-SYS 
via a simulation mapping. The simulation maps states of DEL-ONE-SHOT-AND-BUF 
to states of the original controller, ONE-SHOT. Note that the use of the hiding 
operator <f> in the definition of DEL-ONE-SHOT-AND-BUF makes the two automata 
comparable (Section 2.5). We use the simulation and Theorem 2.5.1 to show that 
DEL-ONE-SHOT-AND-BUF implements ONE-SHOT. Then, the timeliness and safety 
properties of DEL-ONE-SHOT follow from Theorem 2.6.2. 

The intuition that suggests this type of proof is as follows: ONE-SHOT exhibits 
all possible behaviors that engage the brake exactly once and that satisfy the time- 
liness and safety properties. Therefore, the automaton ONE-SHOT is itself a form of 
specification for those behaviors — that is, every correct brake-controller which only 
engages the brake once is an implementation of ONE-SHOT. Since the example con- 
troller of this chapter, DEL-ONE-SHOT, only brakes once, we expect that it satisfies 
the timeliness and safety properties if and only if the composition of DEL-ONE-SHOT 
and BUFFER implements ONE-SHOT. One direction of the "if and only if" comes from 



Figure 4-2 Comparison of ONE-SHOT-SYS and DEL-ONE-SHOT-SYS. 
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Theorem 3.4.1 and is the proof method we use. The other direction is based on our 
claim that ONE-SHOT exhibits all possible behaviors that engage the brake exactly 
once. 

Notice that the safety and timeliness properties only mention variables in TRAIN. 
In light of this, it may appear counter-intuitive that the simulation mapping ex- 
cludes the train. Consider Figure 4-2, which shows the automata and inter-automaton 
communication of ONE-SHOT-SYS and DEL-ONE-SHOT-SYS together. The dark ver- 
tical line represents a common interface in both systems, namely the interface to 
TRAIN. A consequence of our simulation mapping is that the external behavior of 
DEL-ONE-SHOT-AND-BUF is a subset of the external behavior of ONE-SHOT. Their 
external behavior is precisely the behavior across the dark line and this is all the 
input that TRAIN receives; therefore train's behavior in the buffered case is a subset 
of its behavior in the unbuffered case. Therefore, the timeliness and safety proper- 
ties, which involve only variables of TRAIN, extend from the unbuffered case to the 
buffered case. 

In the following three subsections we give some supporting lemmas, the simulation 
mapping, and then the final correctness result in Theorem 4.5.6. 



Supporting Lemmas 

The following lemma helps reduce the number of cases that need to be considered in 
the simulation proof. 

Lemma 4.5.2 In all reachable states of DEL-ONE-SHOT-AND-BUF exactly one of the 
following is true: 

1. phase = idle A request = none 

2. phase = braking A request = on 

3. phase = braking A request = none 



4- phase = done A request = off 
5. phase = done A request = none 

Furthermore, all transitions lead from a state in one category to a state in the same 
or immediately subsequent category. 

Proof: Simple induction, uses Lemma 4.5.1. I 

The following two technical lemmas help make the simulation proof more readable. 
Both lemmas concern the time bounds on the idle phase. 

Lemma 4.5.3 In all reachable states of DEL-ONE-SHOT, the following holds: 
phase = idle => first(ON) = A last(OFF) = A' 

Proof: Exactly analogous to Lemma 3.6.1. I 

Lemma 4.5.4 In all reachable states of DEL-ONE-SHOT-AND-BUF 
the following holds: 

(phase = braking A request ^ none) ==>■ last(BUFF) < A 1 + S + = A 
Proof: Simple induction, uses Lemma 4.5.2. I 

Simulation 

In this section we present a simulation relation R from DEL-ONE-SHOT-AND-BUF to 
ONE-SHOT. The key insight is that since external behavior must be preserved, the 
timing of external actions must coincide, specifically brakeOn and brakeOf f . 

Let s denote a state in the implementation (DEL-ONE-SHOT-AND-BUF), and u 
denote a state in the specification (ONE-SHOT); the states are related via R (denoted 
sRu) when the following two conditions hold: 

1. u.now = s.now 

2. By cases of s. phase: 

(a) idle, then u. phase = idle 

(b) braking, by cases of s. request: 

i. on, then u. phase = idle 
ii. none, then u. phase = braking and 
u.first(OFF) < s.first(OFF) + 6~ and 
u.last(OFF) > s.last(OFF) + 6+ 

(c) done, by cases of s. request: 



Figure 4-3 Overview of Simulation 
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i. off, then u.phase = braking and 
u.first(OFF) < s.first(BUFF) and 
u.last(OFF) > s.last(BUFF) 

ii. none, then u.phase = done 



Intuitively, the simulation is mapping the "virtual" phases of the implementation, 
DEL-ONE-SHOT-AND-BUF, to the actual phases of the specification, ONE-SHOT. This 
is illustrated in Figure 4-3. The figure depicts an execution of ONE-SHOT above 
a corresponding execution of DEL-ONE-SHOT. A virtual phase of DEL-ONE-SHOTis 
the portion of its execution that corresponds to an actual phase of ONE-SHOT. For 
example the virtual idle phase consists of the period between the hrst and second 
dotted line. The second and third dotted lines represent the times when brakeOn and 
brakeOf f actions occur, respectively. The figure also shows how mapping clause 2 
applies to different portions of the execution. 

The proof that the relation R is in fact a simulation mapping appears below. The 
form of simulation proofs is that of an exhaustive case analysis. To those familiar 
with the style of simulation proofs, this one is straightforward and unremarkable. 

Lemma 4.5.5 The above relation R is a simulation mapping from 
DEL-ONE-SHOT-AND-BUF to ONE-SHOT. 



Proof: Let s follow from s' in one discrete transition labeled by action tt or in one 
trajectory and let sRu. We must find u' such that s'Ru' and there exists an execution 
fragment from u to u' with the same trace as tt. We break by cases depending on the 
type of step and its label: 



1. If s leads to s' via a trajectory then we must show that there is an equivalent 
trajectory enabled from u. Since the barriers to time progress are the last(-) 
variables, it is sufficient to show that they are all greater in the specification. 
More exactly: 

min{u.last(ON),u.last(OFF)} 

> min{s.last(ON),s.last(OFF),s.last(BUFF)} 

Cases by u. phase: 

(a) u. phase = idle 

The OFF task is disabled in u so u.last(OFF) = oo and we are concerned 
only with u.last(ON). From the relation R we can break into the following 
two cases: 

i. s.phase = idle - then s.last(OFF) = oo and s.last(BUFF) = oo (by 
automaton definition and Lemma 4.5.2). By Lemmas 3.6.1 and 4.5.3 
u.last(ON) = A and s.last(ON) = A' and by definition A > A'. 

ii. s.phase = braking A s. request ^ none - Follows from Lemmas 3.6.1 
and 4.5.4. 

(b) u. phase = braking 

The ON task is disabled in u so u.last(ON) = oo and we are concerned 
only with u.last( OFF). From the relation R we can break into the following 
two cases: 

i. s.phase = braking A s. request = none - then s.last(ON) = oo and 
s.last(BUFF) = oo. By clause 2(b)ii of the relation u.last(OFF) = 
s.last(0FF) + 6+. 

ii. s.phase = done A s. request ^ none - then s.last(ON) = s.last(OFF) = 
oo. By clause 2(c)i of the relation u.last(OFF) = s.last(BUFF). 

(c) u.phase = done 

Trivial. Both tasks OFF and ON are disabled in u, so u.last(OFF) = 
u.last(ON) = oo. 

2. If 7r is buf BrakeOn then let u' = u and the execution fragment be empty. We 
must show that s'Ru'. Note that s.phase = idle by the definition of the 
DEL-ONE-SHOT automaton. Also note that s. request = none by Lemma 4.5.1 
(non- violation). The results follows by clause 2a of the relation. 

3. If 7r is buf BrakeOff then it is similar to the previous case. We let u' = u and 
the execution fragment is empty. It follows from clause 2(c)i that s'Ru' . 

4. If 7r is brakeOn then let u' be the unique state that follows u via the brakeOn 
action and let the execution fragment contain only that action. We must show 



that brakeOn is enabled in u and that s'Ru'. Note that s. request = on by the 
definition of the BUFFER automaton. By Lemma 4.5.2 we know that s.phase = 
braking. Therefore by clause 2a of the relation we know that u.phase = idle. 
Since u.first(ON) = by Lemma 3.6.1, brakeOn is enabled in u. It remains 
to show that u! satisfies the relation. Since s' satisfies the antecedent of clause 
2(b)ii, u! must satisfy its consequent. By the definitions of B, B' } C, C it does. 

5. If 7r is brakeOf f then we proceed much as in the above case. Let u! be the unique 
state that follows u via the brakeOf f action and let the execution fragment con- 
tain only that action. First, s. request = off by the definition of the BUFFER 
automaton. By Lemma 4.5.2, s.phase = done. By clause 2(c)z of the rela- 
tion we know that u.phase = braking and that [u.first(OFF) } u.last(OFF)] D 
[s.first(BUFF) } s.last(BUFF)] and brakeOf f is enabled in s, therefore it is en- 
abled in u. Finally s'Ru 1 by clause 2(c)ii. 

These are all the cases of tt. I 



Using the Simulation 

In this section we use the above simulation to prove that DEL-ONE-SHOT is a correct 
buffered-brake-controller. 

Theorem 4.5.6 Automaton DEL-ONE-SHOT is a correct buffered-brake-controller. 

We must show that DEL-ONE-SHOT-AND-BUF is a correct brake-controller. 
By Lemma 4.5.5 and Theorem 2.5.1: 

DEL-ONE-SHOT-AND-BUF < ONE-SHOT 

By Theorem 3.4.1 and Theorem 3.6.14 DEL-ONE-SHOT-AND-BUF is a correct brake- 
controller. 



Chapter 5 

Deceleration Case 3: 
Feedback and No Delay 



In this chapter we describe a more complex model of the deceleration problem where 
the train provides the controller with sensor feedback at periodic intervals. We define 
a new train automaton called SENSOR-TRAIN. We also define correctness conditions, 
give an example controller and prove that it is correct. Figure 5-1 illustrates the 
components and their communication. 



5.1 The SENSOR-TRAIN Automaton 

The SENSOR-TRAIN automaton appears in Table 5.1. It accepts accel(a) messages 
which are requests to accelerate at a rate a £ [c m i n + c err , c max ]. If a is the requested 
acceleration then the achieved acceleration of the train is in the interval [a — c err , a]. 
This is similar to the behavior of TRAIN from Section 3.2 in that the acceleration 
is non-deterministically chosen from an interval. It differs in that the controller can 
choose one of the endpoints of the fixed length interval and hence adjust the interval 
up or down. The train provides sensor information periodically; it sends a status 
message giving the current values of its variables acc } i, and x every 6 S time units. 
The variable ace stores the most recent acceleration request. The variable next is a 
deadline variable which stores the time of the next status action. 

Figure 5-1 Overview of Feedback Deceleration Model 
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Table 5.1 The SENSOR-TRAIN automaton. 



Actions: Inputs: accel(a) for a £ [c m i n + c err , c max ] 

Outputs: status(a, v,p) for a, v,p £ IR 
Vars: Outputs: £ £ IR, initially x = c s 

x £ IR, initially i = c s 

x £ IR, initially x = c s 

ace £ [c min + c err , CmaJ, initially c s 

nea;* £ E^°, initially 

now £ E^°, initially 

Discrete Transitions: 

accel(a): 

Eff: ace := a 

x :£ [a — c err , a] 
status(a, u,p): 

Pre: a = acc } v = i, p = x and now; = next 

Eff: Tieai^ := now + <5 S 

Trajectories: 

w.acc and w.next are constant functions 

u>.;r is an integrable function with range [u>(0).acc — c err , w(0).acc] 

For all t £ 7 the following hold: 

wit). now = w(0).now + t 

wit). now < ne;r£ 

w(t).x = w(0).x + J t«(s).x o?s 

w(t).x = w(0).x + J u>(s).i o?s 



5.2 Properties of SENSOR-TRAIN 

The following two properties of SENSOR-TRAIN are similar to the properties of TRAIN 
proved in Lemmas 3.3.2 and 3.3.4. The hrst bounds change in velocity by change in 
time. The second bounds change in position by change in velocity. 

Lemma 5.2.1 For all closed trajectories w of SENSOR-TRAIN where s is the initial 
and s 1 is the final state of w the following holds: 

acc(now — now) > x — x > [ace — c eTT )(now' — now) 

Proof: As in the hrst part of Lemma 3.3.2, except that ace and (ace — c err ) replace 
c max and Cmin respectively I 



Lemma 5.2.2 For all closed trajectories w of SENSOR-TRAIN where s is the initial 
and s' is the final state of w, if ace < and < x' then the following holds: 



(x') 2 - x 2 , (x'Y - x 2 



> x' — X > 



2acc 2(acc — c err ) 

Proof: Similar to Lemma 3.3.4, except that ace and (ace — c err ) replace ^s and c m i n 
respectively. I 

The following property is like the now < last(-) property for MMT automata, 
Theorem 2.8.1. 

Lemma 5.2.3 In all reachable states of SENSOR-TRAIN the following holds: 
< next — now < 6 S 

Proof: Simple induction. I 



5.3 Definition of Controller Correctness, Revisited 

We define a correct controller-under-feedback to be a hybrid I/O automaton with no 
external variables and with output actions accel(a) for a £ [c m i n + c err , c max ] that 
when composed with SENSOR-TRAIN yields an automaton whose hybrid traces satisfy 
the timeliness and safety properties from Section 3.4. These are restated here for 
convenience: 

Timeliness There exists a constant t £ IR-° such that for all hybrid traces if there 
exists a state of the trace in which now = t, then there is a state of the trace in 
which x = Cf. 

Safety In all states of all hybrid traces the following holds: 

X Cf '' C m j n f \ X \ Cmaxf* 



5.4 Parameters, Revisited 

In order to guarantee that a valid controller exists, we impose the following constraints 
on the parameters: 

1. c s < c f 

Z. Cg s> Cm ax f _ C m i n f s> U 

4. 6 S > 



^* C m j n <^. Cmin -\- C err \ U _^ Cmax ^err <^. Cmax 

6 2 -6 2 

fi /-> — r > maxf 5 

-^V mmT<--err J 

' • C max f C mm f ^ Cinin^s 

Note that these constraints supersede the original constraints given in Chapter 3. 
Informally the constraints say the following: (1) the final position is past the initial 
position; (2) the task is to decelerate the train to a well-defined interval but not 
to reverse the train; (3) the uncertainty in acceleration is non-zero; (4) the interval 
between sensor observations is non-zero; (5) certain commands to the train can guar- 
antee periods of strictly negative or non-negative acceleration; (6) there is enough 
distance to brake, given the weakest braking that can occur after a request for the 
strongest braking; (7) the target interval of velocities is wide enough. Constraint 7 
is only one of a number of constraints that make the target velocity interval wide 
enough for there to be some correct controller. We chose this form of constraint 7 
because it is necessary for the correctness of the example controller of this chapter. 

Recall that in the description of SENSOR-TRAIN the initial values of both ace and 
x are set to c s . In order to avoid a tedious treatment of certain initial conditions, 
we assume that the train is initially at a convenient acceleration. Let c s be the 
acceleration needed to reach c max f at exactly Cf, as follows: 

A2 -2 



^maxf 



c; 



2(cf - c s ) 
Notice that c s is negative. 

5.5 Example Controller: ZIG-ZAG 

Controlling the train in the presence of sensory feedback appears to require a sub- 
stantially different algorithm from that in the non-feedback case. Here we give an 
example valid controller-under-feedback called ZIG-ZAG. The system composed of 
SENSOR-TRAIN and ZIG-ZAG is called ZIG-ZAG-SYS. We describe ZIG-ZAG in Ta- 
ble 5.2. 

We explain informally the behavior of ZIG-ZAG. The controller takes no action 
unless it receives a status(a, v } p) message in which v < c max f; this is guaranteed 
to occur eventually and before the final position because of our choice of the initial 
negative acceleration c s . This is an arbitrary choice in the design of ZIG-ZAG — there 
are other correct controllers that adjust the acceleration earlier. Once the controller is 
informed that the velocity of the train in below c max f, it immediately send an accel(a) 
message where a is the acceleration which will accelerate the train from its current 
velocity to c max f in 6 S time (if that acceleration is higher than c max , the largest allowed 
value of a, then it uses c max .) . If the train doesn't achieve the requested acceleration 
then the velocity in 6 S time will be less than c max f. Constraint 7 on the parameters 



Table 5.2 The ZIG-ZAG automaton. 



Actions: Inputs: status(a, v,p) for a, v,p G 

Outputs: accel(a) for a G [c m i n + c err , c n 
Vars: Internal: senrf G [cmin + c err , c max ] U {none}, initially none 



°err t ^maxj 



Discrete Transitions: 

status(a, v,p): 
Eff: 

if v < c maxf then 

send := min ( c max , Cma | f ~"" 

accel(a): 

Pre: send = a 
Eff: senrf := none 

Trajectories: 

w.send is a constant function 

if w is not a trivial trajectory then 

w(0).send = none 
for all t G / the following holds: 

wit). now = w(0).now + t 



from Section 5.4 is sufficient to ensure that the interval [c max f, c m i n f] is wide enough 
that this strategy doesn't cause the velocity to dip below c m i n f. In the definition of 
the trajectory set, the first "if" statement ensures that time progresses only if the 
controller has nothing to send. 

The controller is called ZIG-ZAG because of the shape of the curve in x X now space 
of the worst-case behavior of ZIG-ZAG-SYS (recall that ZIG-ZAG-SYS is the composition 
of SENSOR-TRAIN and ZIG-ZAG). Figure 5-2 depicts a possible behavior for the system; 
it assumes constant acceleration. The train begins at time zero with velocity c s and 
acceleration c s . If it achieved c s acceleration it would reach the goal velocity of Qnaxf 
at exactly Cf (the upper dotted line). However, for the first three 6 S periods it only 
achieves c s — c err acceleration (the solid line). At that point the controller sees that 
x < c max f and changes the acceleration (first bend in solid line). Every 6 S time units 
the controller continues to adjust acceleration so that the highest it will reach is Cm ax f. 



Figure 5-2 Possible behavior of ZIG-ZAG-SYS. 
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5.6 Correctness of ZIG-ZAG 

The structure of the proof is very similar to that of the simple case examined in 
Chapter 3: first, we show the timeliness property via a global lower bound on velocity; 
second, we show the safety property via a more complex invariant that has as a sub- 
case the invariant used in Chapter 3. 



5.6.1 Timeliness 

In this section we prove the timeliness property. The hrst lemma is a technical lemma 
that says that whenever the controller is going to send a new acceleration, there is 
6 S time until the next status message. This is obvious because the status messages 
are sent at 6 S intervals and the controller responds to them immediately. 

Lemma 5.6.1 In all reachable states of ZIG-ZAG-SYS the following holds: 
send ^ none ==>■ next = now + 6 S 

Proof: Trivial induction. I 

The next lemma, Lemma 5.6.2, is the major new result needed to prove the 
timeliness property. As in Chapter 3, we would like to prove the timeliness property 
with the invariant x > c m i n f. However, this invariant cannot be proved directly with 
an inductive argument. Once again, we strengthen the invariant to yield an invariant 
assertion that can be proved inductively; the weaker invariant follows as a corollary. 

The stronger invariant appears in Lemma 5.6.2. It is an invariant that describes 
a lower bound on velocity at the current time and for the near future — the current 



sensory interval. This property uses a set of implications with mutually exclusive and 
exhaustive antecedents. Each implication corresponds to one of the periodic logical 
phases of the system: send = none, when the ZIG-ZAG is waiting for the next status 
message; and send ^ none, when ZIG-ZAG has just received a status message and 
is about to send a new accel command. The invariant makes a different claim for 
each of these phases. On the one hand, the invariant says that if send = none then 
the current velocity is above c m i n f and the velocity at the time of the next status 
message will be also. The worst-case velocity at the time of the next status message 
is calculated using the current lower bound on acceleration, ace — c err , and the time 
left until the next status message, next — now. This type of calculation appears again 
in more complex forms in subsequent sections and chapters. On the other hand, the 
invariant says that if send ^ none then the current velocity is above c m i n f and the 
velocity at the time of the next status message will be also. In this case, the worst-cast 
velocity at the time of the next status message is calculated using the acceleration 
that the controller is about to send the train, namely the variable send itself. This 
type of invariant appears again later in more complex forms. 

Lemma 5.6.2 In all reachable states of ZIG-ZAG-SYS, the following hold: 

1. send = none ==> x > c m i n f A x + (ace — c eTT )(next — now) > c m i n f 

2. send ^ none ==> x > c m i n f A x + (send — c eTT )6 s > c m i n f 

Proof: By induction. Notice that the antecedents of the two implications are mu- 
tually exclusive and exhaustive; we will refer to them as Rule I and 2. We say that 
a rule applies when it's antecedent is true and that it holds when it applies and its 
consequent is true (or when it doesn't apply). 

Basis: In the initial state x > c max f so Rule I applies. It holds because of our 
assumptions on the parameters, the definition of c s , and the definition of the initial 
states of the automata. 

Induction: Suppose the property is true in state s; we must show that it is true 
in s 1 which follows from s in one discrete transition labeled by action tt or in one 
trajectory. For the sake of brevity, we denote variables in the post-state by adding 
primes, e.g. we write now' instead of s' .now. We brake by cases on the type of step 
and its label: accel, status, or trajectory. 

1. 7r = accel: notice that send ^ none by the action's precondition, so Rule 
2 applies in s and by the inductive hypothesis it holds. The only variables 
which change are send and ace; the action sets ace 1 = send and send 1 = none. 
Therefore Rule I must apply in s' . We must show that it holds. Clearly, 
x 1 = x > c m i n f by the inductive hypothesis. By Lemma 5.6.1 next — now = 6 S 
and because none of these variables change next 1 — now 1 = 6 S . By substituting 
next 1 — now 1 = 6 S} ace 1 = send and send 1 = none into the inequality in Rule 2 
we get : 



x + (ace 1 — c eTT )(next' — now!) = x + (send 
This shows that Rule 1 holds in s' . 



r )S s > C 



^minf 



2. 7T = status: notice that next = now by the action's precondition, so next ^ 
now + 6 S and by the contra-positive of Lemma 5.6.1 send = none; therefore, 
Rule 1 applies in s and by the inductive hypothesis it holds. The only variables 
which change are send and next. We break by cases of send 1 : 

(a) send 1 = none: Rule 1 applies in s'; must show that it holds. According 

<5 S , and 

min^s* 



to the automata definitions x' = x = v > c max f, next! — now' = 
acc' — c eTT > c mm . By assumption on the parameters: c max f— c m i n f > — c, 
From these, we reach the desired conclusion with some algebra: 
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Thus Rule 1 holds in s' . 

(b) send' ^ none: Rule 2 applies in s'; must show that it holds. Above we 
showed that next = now and Rule 1 holds in state s from which we know 
that x > c m i n f. This is half of Rule 2; it remains to show the other half. 



According to the automata definitions: send' 
assumption on the parameters c max — c err 
Rule 2 applies trivially. Assume that send' 
yields the desired result: 
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Thus Rule 2 holds in s' . 



3. The step is a trajectory: then send = send' = none according to the trajecto- 
ries of the controller. Thus, Rule 1 holds in s, applies in s' and must be shown 



to hold in s'. This case uses Lemma 5.2.1, the inductive hypothesis and some 

simple algebra. 

Notice that ace = acc' } so let X = (ace — c err ) = (ace 1 — c err ): 

x + X (next — now) > c m i n f inductive hypothesis 

x' — x > X(novJ — now) by Lemma 5.2.1 
x' — x — X(nowf — now) > subtract 

x + x' — x + X(next — now) 

—X^owf — now) > c m i n f add 

x' + X (next — now ') > c m i n f cancel 

For the x > c m i n f requirement: by Lemma 5.2.3 next — now > 0, thus if 
X > then x' > x > c m i n f; otherwise, x' > x' + X(next — now 1 ) > c m i n f 
(by Lemma 5.2.3). Thus Rule 1 holds in s' . 



Corollary 5.6.3 In all reachable states of ZIG-ZAG-SYS the following holds: 

Proof: Directly from 5.6.2. The antecedents form an exhaustive set of cases, and in 
all cases the property is true. I 

This leads to the timeliness property as Lemma 3.6.6 did in Chapter 3. The 
corollaries which yield the timeliness property are exactly analogous and are not 
restated here. The final result is stated in Theorem 5.6.8. 



5.6.2 Safety 

The following technical lemma is says that under certain conditions a certain inequal- 
ity is maintained during trajectories. Informally, the inequality tests whether there 
remains enough distance to brake the train to below c^^f. This inequality appeared 
extensively in the proof of the safety property in Section 3.6.2. 

Lemma 5.6.4 Let w be a closed trajectory of ZIG-ZAG-SYS where s is the initial state 
and s 1 is the final state of w. If ace = c s , x < Cf ; and x' < c' t then 

^2 -2 -2 / • A2 

maxf — X , „ I v. C maxf ~ \ X ) 



Cf — X > ==?■ C{ — X > 



s s 

Proof: The proof is similar to those in Section 3.6.2. 
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The following lemma is the major result needed to prove the safety property. It 
is similar to two other results: (1) Corollary 3.6.12 and its supporting lemmas, which 
used a similar equation to bound "distance remaining"; and, (2) Lemma 5.6.2 of this 
section, which provides a set of implication with an exhaustive set of antecedents. 
Each of the clauses can be associated with a portion of the solid line in the graph 
in Figure 5-2. The hrst clause applies to the initial downward segment; it says that 
before passing the c max f threshold the following hold: the acceleration c s is in effect; 
the controller is not sending any commands; and there is enough distance left to 
brake at the current acceleration. The second and third clauses guarantee that once 
the velocity has dipped below c max f, it will never rise above c max f. These clauses 
guarantee an upper bound in a manner analogous to the clauses of Lemma 5.6.2 
which guaranteed a lower bound. 

Lemma 5.6.5 In all reachable states of ZIG-ZAG-SYS the following hold: 

1. x > c max f ==>■ ace = c s A send = none A ( (x < Cf) =^ Cf — x > 2 ~ 

2. x < c max f A send = none ==? (x + acc(next — now)) < c max f 

3. x < c max f A send ^ none ==? (x + send(6 s )) < c max f 

Proof: This is an inductive proof very similar to the proof of Lemma 5.6.2 above. 
As in that lemma, the property is the conjunction of a set of implications whose 
antecedents are mutually exclusive and exhaustive. We use similar terminology here, 
calling them Rules 1, 2, and 3. Notice that Rules 2 and 3 are analogous to Rules 1 
and 2 of the previous lemma except that they guarantee an upper bound instead of 
a lower bound. We omit portions of this proof which are directly analogous. 

Basis: In the initial state Rule 1 applies and is satisfied trivially. Induction: 
Suppose the property is true in state s; we must show that it is true in s' which 
follows from s in one step — either a discrete step labeled by action i or a trajectory. 
For the sake of brevity, we denote variables in the post-state by adding primes, e.g. 
we write now 1 instead of s' .now. We brake by cases on the type of step and the label 
7r: accel, status, or trajectory. 

1. 7r = accel: Either x < c max f or not. 



(a) x < c max f: This case is exactly analogous to the tt = accel case of the 
proof of Lemma 5.6.2. Here, Rule 3 holds in state s and Rule 2 is shown 
to hold in state s' . We abbreviate the proof by noting that ace' = send 
and next' — now' = 6 S . 

(b) x > c max f: by the inductive hypothesis Rule 1 holds in s and therefore 
send = none; however in that case, this action was not enabled in s. 
Therefore x > c max f is impossible for the accel action case. 

2. 7r = status: Either x < c max f or not. 

(a) x < c max f: This case is exactly analogous to the tt = status case of the 
proof of Lemma 5.6.2. Here, Rule 2 holds in state s and Rule 3 can be 
shown to hold in state s' . We omit the proof. 

(b) x > c max f: Thus, Rule 1 holds in states s. By the automata definitions 
only variable next changes as a result of this action (because x > Cmaxf)- 
Since next does not appear in Rule 1, it must continue to hold in state s'. 

3. The step is a trajectory: Either x < c max f 

(a) x < c max f: This case is exactly analogous to the trajectory in the proof of 
Lemma 5.6.2. Here, Rule 2 holds in state s and can be shown to also hold 
in state s' . We omit the proof. 

(b) x > c max f: Thus, Rule 1 holds in states s. By the definition of automata, 
we know that only the variables now, x } i, and x are modified by this 
action. Therefore, we know that ace' = ace = c s and send' = send = none. 
There are two cases, either Rule 1 holds in s' or Rule 2 does. 

i. x' > c max f: Rule 1 applies in s' and we must show that it holds. This 

is guaranteed by Lemma 5.6.4. 
ii. x' < c max f: Rule 2 applies in s' . Note that ace' = c s is negative, while 
(next — now') is always positive by Lemma 5.2.3. Since x' < c max f, we 
know x' + ace' (next — now') < c max f. Therefore Rule 2 holds in s' . 



The following corollaries correspond directly to Corollaries 3.6.12 and 3.6.13. 
Corollary 5.6.6 In all reachable states of ZIG-ZAG-SYS the following holds: 

(x < Cf) =^ C{ — X > 



C maxf X 



2c s 

Proof: Directly from 5.6.5. If the hrst implication applies, then it appears in the 
consequent. If the second implication or third applies, then c^ axf — x 2 is positive, 
hence, the fraction is negative and the inequality holds. These cases are exhaustive. 

■ 

The following corollary establishes the safety property. 



Corollary 5.6.7 In all reachable states of ZIG-ZAG-SYS the following holds: 

Cf X ,' C max f ^_ X ^_ C m j n f 

Proof: Directly from 5.6.6 and 5.6.3. 



We summarize the correctness results in the following theorem. 

Theorem 5.6.8 Automaton ZIG-ZAG is a correct controller-under- feedback. 

Proof: We must show that the hybrid traces of ZIG-ZAG-SYS satisfy the timeliness 
and safety properties (see Section 5.3). As mentioned at the end of Section 5.6.1, the 
timeliness property follows from Corollary 5.6.3 just as it did from Lemma 3.6.6 in 
Chapter 3. We have omitted the intermediate results. Corollary 5.6.7 is exactly the 
safety property. I 



Chapter 6 

Deceleration Case 4: 
Delay and Feedback 



In this chapter we combine periodic sensor feedback and command delay. As in Chap- 
ter 4, we introduce delay via a buffer called ACC-BUFFER. We make no modification 
to the SENSOR-TRAIN automaton. We define a notion of a correct controller for this 
buffered system. We give an example of a correct controller called DEL-ZIG-ZAG that 
involves only minor modifications to the ZIG-ZAG controller of Chapter 5. Figure 6-1 
illustrates the components and their communication. 

In Chapter 4, we use a simulation based argument to prove that the composition 
of DEL-ONE-SHOT and BUFFER implements ONE-SHOT, the highly nondeterministic 
controller of Chapter 3. One might expect a similar development in this chapter — 
namely that we use a simulation proof to show that the composition of DEL-ZIG-ZAG 
and ACC-BUFFER implements ZIG-ZAG, the controller of Chapter 5. This is not 
the case; we prove the correctness of DEL-ZIG-ZAG directly. In fact, no simulation 
proof is possible because the composition of any controller and ACC-BUFFER can not 
implement ZIG-ZAG. Informally this is clear because ACC-BUFFER will introduce a 
delay between the time when the train gives the controller sensor input and when the 
train receives the related command. No such delay occurs for ZIG-ZAG — it responds 
to each sensor input without delay. There remains the question of whether some other 
choice of example controllers could have enabled the use of a simulation proof in this 
chapter in a manner analogous to Chapter 4. We address that issue in Chapter 7. 

Figure 6-1 Overview of Feedback with Delay Deceleration Model 



SENSOR-TRAIN 



accel(a) 



ACC-BUFFER 



buf Accel(a) 



status(a, v,p) 



A Controller 



71 



6.1 The ACC-BUFFER Automaton 

The buffer, called ACC-BUFFER, has much the same structure as that of Chapter 4. 
It appears in Table 6.1 as an MMT-specihcation. 

Table 6.1 The ACC-BUFFER automaton. 



Actions: Inputs: buf Accel(a) for a £ [c m i n + c err , Cm ax ] 

Outputs: accel(a) for a £ [c m i n + c err , c max ] 
Vars: Internal: request £ [c m i n + c err , c max ] U {none}, initially none 

violation, boolean, initially false 

Discrete Transitions: 

buf Accel(a): 

Eff: if request = none then 
request := a 
else 

violation := true 
accel(a): 

Pre: request = a 
Eff: request := none 

Tasks: BUFF = {accel(a)} : [S~,6+] 



The variable request stores a command while it is being buffered. The major 
difference between ACC-BUFFER and BUFFER of Chapter 4 is the type of the command 
being buffered. The variable violation is true when a new command from the controller 
arrives before the previous one has exited the buffer, that is when the buffer overflows. 
We use the history variable violation to flag this error condition. 



6.2 Definition of Controller Correctness, Revisited 

A valid controller-under-feedback-and-delay is an HIOA with no external variables 
and with output actions buf Accel(a) for a £ [c m i n + c err , c max ] that when composed 
with ACC-BUFFER yeilds a correct controller-under-feedback as defined in Section 5.3. 
In Section 4.2 we use a hiding operator <f> in the definition of correctness for a 
buff ered-brake- controller. We do not need such a hiding operator here because we are 
not comparing hybrid traces as one does in a simulation proof. 



6.3 Parameters, Revisited 

In order to guarantee that a valid controller, exists we impose the following constraints 
on the parameters: 

1. C s < C{ 

L. C s s> C ma xf _ ^minf ^ " 

4. 6 S > 6+ > 6- > 

<-*• C m j n <v. Cmin -p C err <v. U _^ C ma x Cerr <v. C ma x 

■2 "2 

6. Cf - c s > > axf ~- Cs ^ 

' • C max f Cminf ^ Cinin^s T ^ J 

^* ^ max f Cminf ^_ C err yO -\- S ) -\- \C InajX Cminjl^ ^ ) 

Constraints 1, 2, 3, 5, and 6 are identical to the same numbered constraints from 
Section 5.4; they are restated here for convenience. Constraint 4 requires that the 
delay interval be well-defined and not zero and that it be shorter than the frequency 
of sensor feedback. Constraints 7 and 8 both ensure that the target velocity interval 
is wide enough. As in Chapter 5, other choices for constraints 7 and 8 are reasonable, 
but as stated the constraints are necessary for the correctness of the example controller 
of this chapter. 

For convenience, we continue to assume as in Chapter 5 that the initial values of 
ace and x are set to c s , where: 






C maxf C - 



2(cf - c s ) 
Notice that c s is negative. 

6.4 Example Controller: DEL-ZIG-ZAG 

We do not define a completely new controller for this chapter. Rather, we modify the 
ZIG-ZAG controller of Chapter 5. We define DEL-ZIG-ZAG to be identical to ZIG-ZAG 
except that we rename its output actions accel(a) to buf Accel(a) and redefine the 
tranisitions labeled with the status(a, v } p) input actions, as follows: 



status(a, v } p): 

Eff: if v < c max f then 

if c max f < v + a(8 s + 6 + ) then 
send := maxl c 



el: 



se 



send :- 



mill-"-''* 

s s +s+-s- 



The composition of SENSOR-TRAIN, ACC-BUFFER, and DEL-ZIG-ZAG is called 
DEL-ZIG-ZAG-SYS. 

For each status message, DEL-ZIG-ZAG only takes action if v < c max f; this is 
similar to ZIG-ZAG and allows for an initial braking period at the initial (negative) 
acceleration c s . Once the velocity drops below c max f, the action the controller takes 
depends on whether an adjustment upward or downward is needed in the acceleration 
to keep the velocity below c max f. The two cases are depicted in Figure 6-2 and 
Figure 6-3. The figures show velocity versus time graphs of possible behaviors of 
DEL-ZIG-ZAG-SYS. Time zero in both figures is the time of some status(a, v,p) 
message in which v < Cm ax f. The horizontal dashed lines are the velocity bounds. 
The solid lines form a "bent wedge"; this wedge represents upper and lower bounds 
on the possible behavior of DEL-ZIG-ZAG-SYS. The origin of the wedge is at time zero 
when x = v. The portion of the wedge before the bend bounds the evolution of x while 
the current acceleration is in effect. The bend in the wedge represents the change 
in acceleration when the buffer outputs the controller's command. The portion of 
the wedge after the bend bounds the evolution of x after the controllers requested 
acceleration takes effect. The angles of the first part of the wedge are determined by 
a and a — c err ; the angles of the second part of the wedge are determined by send and 
send— c err . The dotted lines represent the bounds on behavior if a remained in effect. 

Figure 6-2 Adjustment downward by DEL-ZIG-ZAG. 
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Let us focus on Figure 6-2 first. Notice the difference between the time of the 
upper and lower bends in Figure 6-2: the lower side of the wedge bends at time 6~ 
and the upper side at time 6 + . This is because it is an adjustment downward, that 
is send < a. The upper bound on x happens when the buffer delays send as long 



as possible; similarly, the lower bound occurs when the buffer delays send as little 
as possible. The test in the above pseudo-code "if c max f < v + . . . " is true when if 
the current acceleration (dotted line) is allowed to remain in effect then x will exceed 
c max f before the next guaranteed change of acceleration at time 6 S + 6 + . The hrst 
branch of the "if" statement results in an adjustment downward in the acceleration 
as depicted in Figure 6-2. It is adjusted so that the top of the wedge is exactly Cmaxf 
at time 6 S + 6 + . Constraints 7 and 8 on the parameters (see Section 6.3) ensure that 
this choice for send does not result in the bottom of the wedge passing below c m i n f- 

Figure 6-3 Adjustment upward by DEL-ZIG-ZAG. 
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The upward adjustment depicted in Figure 6-3 is analogous to the downward ad- 
justment but reversed. The upper side of the wedge results from the buffer delivering 
the upward adjustment as soon as possible; the lower side of the wedge results from 
the buffer delivering the upward adjustment as late as possible. As before, the "else" 
branch of the "if" statement results in the top of the wedge being at exactly Cmaxf at 
time 6 S + 6 + ; however, the calculation is a bit more complex because the bend in the 
upper side of the wedge occurs earlier, at time 6~ . Once again Constraints 7 and 8 
on the parameters ensure that this choice for send does not result in the bottom of 
the wedge passing below Cminf- 



6.5 Correctness of DEL-ZIG-ZAG 



The proof of correctness of the controller requires proofs of the timeliness and safety 
properties. The structure of the proofs is similar to that of Chapter 5. We hrst prove 
a "non- violation" property and then we prove each correctness property in a separate 
subsection. 



We have presented the buffer using an MMT-specihcation. Since there is only one 
MMT task in the buffer and no other MMT-specihcations to consider, we abbreviate 
first(BUFF) and last(BUFF) as first and last. 

6.5.1 Non- Violation 

In this section we prove that the history variable violation remains false in all exe- 
cutions of DEL-ZIG-ZAG-SYS. It follows as a corollary of the following lemma. 

As in the proof of non- violation in Section refsec:DelayVio, it is sufficient to prove 
the invariant that either send or request is always none. As before we must strengthen 
this invariant so that it may be proved by induction. The lemma proves this stronger 
form that is the conjunction of two implications. Informally, it uses deadline variables 
to say that (I) DEL-ZIG-ZAG only sends commands immediately after status messages 
and (2) ACC-BUFFER will relay requested commands before the next status message. 
It depends primarily on constraint 4 on the parameters: 6 S > 6 + . 

Lemma 6.5.1 In all reachable states of DEL-ZIG-ZAG-SYS the following hold: 

1. send ^ none ==>■ (next = now + 6 S ) A request = none 

2. request ^ none ==>■ (last + 6 S = next + 6 + ) A send = none 

Proof: Proof by induction. The property to be proved consists of the conjunction 
of two implications; we call them Rule I and Rule 2 in the style of the proof of 
Lemma 5.6.2. Note that only one of the Rules can apply and hold in a given state. 
Basis: in the initial state neither rule applies. Induction: Let state s lead to state 
s' via a single step — either a discrete step labeled by action tt or a trajectory. We 
proceed by cases on the type of step and tt: accel, buf Accel, status, or trajectory. 

1. 7r = accel: Rule 2 applies and holds in s. The transition sets request! = none 
and does not affect send. Therefore, neither rule applies in the s' . 

2. 7r = buf Accel: Rule I applies and holds in s'. The transition sets request 1 ^ 
none and send 1 = none. It does not affect now or next and it sets last 1 = 
now + 6 + . By the inductive hypothesis, next = next 1 = now + <5 S , so Rule 2 
applies and holds in s' . 

3. 7r = status: We claim that neither rule applies in s. The precondition for this 
action is now = next; so clearly Rule I cannot apply in s. For the purpose of 
contradiction suppose Rule 2 applied in s, then last-\-6 s = next-\-6 + . However, 
by assumption on the parameters 6 S > <5 + , so last < next and therefore last < 
next = now. But this contradicts Theorem 2.8.1. Thus neither rule applies in s, 
i.e. send = none and request = none. The transition does not affect request so 
request 1 = none and it sets next 1 = now 1 + 6 S . Thus Rule I holds in s' (whether 
or not it applies). 



4. The step is a trajectory: does not affect any of the mentioned variables except 
now. The now variable only appears in Rule f and that rule only applies when 
time passage is forbidden. 

These cases are exhaustive and thus the property holds. I 

The non-violation property for DEL-ZIG-ZAG-SYS is established in the following 
corollary. 

Corollary 6.5.2 In all reachable states of DEL-ZIG-ZAG-SYS violation = false. 

Proof: Violation occurs when request ^ none and a buf Accel action takes place. This 
action is only enabled when send ^ none; however, by Lemma 6.5.1 request = none 
in that case. Therefore the property holds. I 



6.5.2 Timeliness 

The structure of the proof is similar to that in Chapter 5. As in that chapter, the 
major result we require is an invariant that implies the lower bound invariant on 
velocity. The following lemma establishes such a result by strengthening the lower 
bound on velocity. It is analogous to Lemma 5.6.2; it is more complex because of extra 
cases and the uncertainty introduced by the buffer. We have changed the notation 
slightly to accommodate the more complex formulas. The invariant consists of four 
clauses: 1, 2a, 2bi, and 2bii. We explain their informal meaning in terms of the wedges 
of Figures 6-2 and 6-3. Each clause tests that at a certain point in the execution, the 
lower arm of the wedge remains above c m i n f. Clause 1 applies when the controller has 
chosen a command (stored in send) but has not yet passed it to the buffer. Clause 2a 
applies when neither the controller nor the buffer are holding an unsent command. 
Clause 2bi applies when the buffer holds a command which has not been held long 
enough to relay. Clause 2bii applies when the buffer holds a command which has 
been held long enough to relay. 

Lemma 6.5.3 Let J denote z — c err . In all reachable states of DEL-ZIG-ZAG-SYS the 
following hold: 



1. send ^ none ==> request = none A x > c m i n f A 

x + acc(6~) + min( ace, send)(6 + — 6~) + send(6 s ) > c m i n f 

2. send = none ==> 

(a) request = none ==> x > c m i n f A x + acc(next — now + 6 + ) > c m i n f 

(b) request ^ none ==> 



i. now < first 



x > c m i n f A x + acc(first — now) 
6- 



+ min(acc, request)(6 + — 6 ) + request(6 s ) > c m i n f 

ii. now > first ==> x > c m i n f A 

x + min( ace, request)(last — now) + request(6 s ) > c m i n f 

Proof: Proof by induction. As in the proofs of similar lemmas from the previous 
chapter we refer to the parts of the above invariant as "rules". Basis case: In the 
initial state Rule 2a applies. We show that it holds as follows: Note that ace = c s 
and next — now = and x = c s > c max f > cWnf. Thus, it is sufficient to show that 
c max f+c s <5 + > c m inf- This follows from the fact that c s > c^n and parameter constraint 
7. Inductive case: Suppose the property is true in state s; we must show that it is 
true in s 1 which follows from s in one step — either a discrete transition labeled by 
f or a trajectory. For the sake of brevity, we denote variables in the post-state by 
adding primes, e.g. we write now 1 instead of s' .now. We brake by cases on the type 
of step and on tt: accel, buf Accel, status, or trajectory. 

1. 7r = accel: We know request ^ none, so by Lemma 6.5.1 send = none. Fur- 
thermore, now > first, by this actions precondition, so Rule 2bii applies is s and 
holds by the inductive hypothesis. As for the post-state — request! = none and 
send! = none, so Rule 2a applies in s' . We show that it holds by noting that 
ace' = request and no other relevant variables have changed. Substitution and 
Lemma 6.5.1 yield the desired result, as follows: 



last — now 


> 





by Theorem 2.8.1 


Teq 


> 


min( ~acc, Teq) 


definition of min 


m(~acc,Teq)(last — now) +TeqS s 


> 


^minf 


inductive hypothesis 


x + Teq(last — now) + TeqS s 


> 


^minf 


substitute 


x + Teq(last — now + <*) s ) 


> 


^minf 


group 


last + <*) s 


= 


next + <*) + 


by 6.5.1 


x + Teq(next — now + S + ) 


> 


^minf 


substitute 


ace' 


= 


Teq 


automaton definition 


x' + acc'(next' — now 1 + S + ) 


> 


^minf 


substitute 



2. 7r = buf Accel: We know send ^ none so Rule 1 applies in s. It holds by the 
inductive hypothesis. Also, request' ^ none, send' = none, and now' < first', 
so Rule 2bi applies in s' . We must show that it holds. This is trivial because 
request 1 = send and first = now + 6~ . 

3. 7r = status: As in the same case in the proof of Lemma 6.5.1, we know that 
send = none and request = none; thus, Rule 2a applies in s and it holds by the 
inductive hypothesis. We break by cases: 

(a) send' = none, so Rule 2a applies in s' . It holds because none of the 
variables in its consequent are affected by the transition. 



(b) send! ^ none, so Rule 1 applies in s' . Note that a = acc } so we write 
ace instead; similarly for v and x. Also note that now = next by the 
actions precondition, and x < c max f by the actions effect. Finally, note 
that send and next are the only variables modified on this transition. We 
break by cases on the branch of the conditional taken in the effect clause 
in DEL-ZIG-ZAG. 



i- c max f < x + acc(6 s + 6 + ) — In this case, we hrst resolve the "min" 

operator by showing that send 1 < ace. As follows: 

send' = c maxf-^-iaccj — automaton definition 

x + (acc)S + + send!S s = c max f simplify 

Cmaxf < x + acc(S s + S + ) case 

x + (acc)S + + send!S s < x + acc(S s + S + ) substitute 

send!S s < accS s cancel 

^ s > parameter assumption 

send! < ace divide 



Now we must show that x + acc6~ + send'(6 + — 6~ + 6 S ) > c m i n f. First, 
notice that send 1 < ace implies that < ace — send'. Also, ace is 
bounded above by c^ax and send' below by c m i n . This justifies the hrst 
inequality that appears below: 



c'max — c'min > acc — send' > above 

Cmaxf C err ^0 -\- S J 

— (c'max — c ' m i n )(^ + — 8~) > c m i n f parameter assumption 

S + > S~ > parameter assumption 

Cmaxf C err ^0 -\- s j 

— (acc — send')(S + — 8~) > c m i n f substitute 

x + (acc)S + + send!S s = c max f as above 
+ (acc)S + + send!S s — c err (S~ + S s ) 

— (acc — send')(S + — 8~) > c m i n f substitute 
x + ~accS~ + send'(S + — 8~ + 8 S ) > c m i n f simplify 



ii- c max f > i + acc(<5 s + 6 + ) — As in the previous case, we hrst resolve 
the "min" operator by showing that send' > acc. As follows: 



send' = Cma g f 7g+_/- — automaton definition 
x + (acc)S~ 

+ send!(S s + S + — 8~) = c max f simplify 

Cmaxf > x + acc(S s + <*> + ) case 
i + (acc)S~ 

+ send'(S s + S + — S~) < i + acc(<*) s + <*) + ) substitute 

send!(S s + S + — S~) < acc(S s + S + — S~) cancel 

(<*> s + S + — 8~) > parameter assumption 

send! < ace divide 



Now we must show that x + acc6 + + send'6 s > c m i n f- By similar 
reasoning to that used in the analogous case above we get the first 
inequality: 

c'max — c'min > send' — ace > above 

Cmaxf C err ^0 T C S J 

-(c'max — c 'min)(^ + — <*>~) > c minf parameter assumption 
S + > S~ > parameter assumption 

Cmaxf C err ^0 -\- S J 

— (send! — ~acc)(S + — 8~) > c m i n f substitute 

x + (acc)S~ + send'(S s + S + — 8~) = c max f as above 
x + (acc)S~ + send!(S s + S + — 8~) 

— c err (S~ + S s ) — (send' — ~acc)(S + — S~) > c m i n f substitute 

i + ~accS + + send'S s > c m i n f simplify 

4. The step is a trajectory: We know that send = send' = none so Rule 2 applies 
in s and s'. This case is straightforward. It uses a similar argument to that of 
the trajectory case in the proof of Lemma 5.6.2. We outline the subcases that 
must be considered but give no details of their proofs: 

(a) request = request 1 = none, so Rule 2a applies in s and s'. 

(b) request = request 1 ^ none, so Rule 2b applies in s and s'. 

i. now < first, so Rule 2bi applies in s. We proceed by cases: 

A. now' < first! ', so Rule 2bi applies in s' . 

B. now' > first! ', so Rule 2bii applies in s' . 
ii. now > first, so Rule 2bii applies in s and s' . 



The following corollary establishes the lower bound on velocity as an invariant of 
DEL-ZIG-ZAG-SYS. 

Corollary 6.5.4 In all reachable state of DEL-ZIG-ZAG-SYS the following holds: 

X i_ Cminf 



Proof: Directly from 6.5.3. The antecedents form an exhaustive set of cases, and in 
all cases the property is true. I 

Corollary 6.5.4 leads to the timeliness property just as Lemma 3.6.6 did in Chap- 
ter 3. The corollaries that yield the timeliness property are exactly analogous and 
are not restated here. The final result is summarized in Theorem 6.5.6 at the end of 
this chapter. 

6.5.3 Safety 

In this section, we give only the major result, Lemma 6.5.5; it leads to the safety 
property for DEL-ZIG-ZAG just as Lemma 5.6.5 for ZIG-ZAG. We do not give the 
intermediate corollaries and lemmas that yield the safety property because they are 
precisely analogous to those of Section 5.6.2. 

Lemma 6.5.5 is similar to both Lemma 5.6.5 and Lemma 6.5.3. It is a strength- 
ening of the desired invariant and its form is the conjunction of a set of implications. 
The form of the first clause borrows from the first clause of Lemma 5.6.5. The form 
of the remaining clauses is analogous to Lemma 6.5.3; however, these clauses check 
that the upper arm of the wedge is lower than c max f whereas the analogous clauses in 
Lemma 6.5.3 check the lower arm of the wedge against c m i n f. 

Lemma 6.5.5 In all reachable states of DEL-ZIG-ZAG-SYS the following hold: 



(■2 ■ 2 

(x < Cf) ==>■ C{ — x > Cma |?. 

Z. X \ Cmaxf '* 

(a) send ^ none ==>■ request = noneA 

x + acc(6~) + max(acc, send)(6 + — 6~) + send(6 s ) < c max f 

(b) send = none ==>■ 

i. request = none ==> x + acc(next — now + 6 + ) < c max f 
ii. request ^ none ==> 

A. now < first ==> 
x-\-acc(first—now)-\-m&x(acc } request)(S + — S~)-\-request(S s ) < c max f 

B. now > first ==> 

x + max(acc, request)(last — now) + request(6 s ) < c max f 

Proof: The invariant in this lemma is very similar to that of Lemma 6.5.3 and so is 
its proof. I 

We summarize the correctness results in the following theorem. 



Theorem 6.5.6 Automaton DEL-ZIG-ZAG is a correct controller-under-feedback-and- 
delay. 

Proof: We must show that the composition of DEL-ZIG-ZAG and ACC-BUFFER is a 
correct controller-under-feedback as defined in Section 5.3. This in turn requires that 
the hybrid traces of DEL-ZIG-ZAG-SYS satisfy the timeliness and safety properties of 
Section 3.4. As mentioned at the end of Section 6.5.2, the timeliness property follows 
from Corollary 6.5.4 just as it did from Lemma 3.6.6 in Chapter 3. We have omitted 
the intermediate results. Similarly, the safety property follows from Lemma 6.5.5 as 
it did from Lemma 5.6.5 in Chapter 5. We have omitted the intermediate results. I 



Chapter 7 
Conclusion 



Summary 

We have presented a case study in the application of hybrid I/O automaton techniques 
to automated transit systems. The purpose of the case study is to test the applicability 
of HIOA techniques to the area of automated transit; in particular, we are concerned 
that HIOA techniques express hybrid systems faithfully and that they allow clear and 
scalable proofs of significant properties of these systems. 

We focused on the deceleration maneuver in which a train's controller slows the 
train to a target velocity range within a given distance. We examined four versions of 
the deceleration maneuver, each with a different model of the communication between 
controller and train: plain, delay, feedback, and feedback with delay. In the plain case 
of Chapter 3, the controller receives no sensor information from the train and controls 
the brake through on and off commands which take effect immediately. The delay 
case of Chapter 4 is like the plain case except that the brake commands are delayed. 
In the feedback case of Chapter 5, the controller receives periodic sensor information 
from the train; the controller can instantly command the train to achieve specific 
positive and negative accelerations subject to some performance error. The feedback 
with delay case of Chapter 6 is like the feedback case except that the acceleration 
commands are delayed. For each case we give a model of the non-controller portion of 
the system, define correctness of a controller, give an example of a correct controller, 
and prove that it is correct. 

We model the train and the controller as HIOAs communicating through discrete 
actions. For the cases with delay, we interpose a third automaton which serves as a 
buffer, delaying messages from the controller to the train. The buffers and some of 
the example controllers are defined using the MMT-specihcations of Section 2.8. The 
other automata are defined using the standard notation of Section 2.7. 

The main correctness conditions for controllers are the timeliness and safety prop- 
erties, defined in Section 3.4. The timeliness property says that the train always 
progresses to the destination location within a fixed time. The safety property says 
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that when the train arrives at the destination it has achieved a velocity in the tar- 
get range. These properties mention only the variables of the train. Since the train 
outputs these variables, we cast these properties as hybrid trace properties of the 
composition of the train and the controller (and a buffer if applicable). 

We use two major proof methods: invariant assertions and simulations. The use 
of invariant assertions is ubiquitous in this case study. The use of invariant assertions 
usually involves strengthening a proposed invariant assertion until it can be proved 
by induction on the steps of a hybrid execution. These inductive proofs have a styl- 
ized form that separates reasoning about discrete behavior (actions) from continuous 
behavior (trajectories). Timing information such as the current time and deadlines 
for events are explicitly modeled in the state as variables (e.g. now, last(OFF)). 
These variables facilitate proofs of timing behavior using invariant assertions. MMT- 
specihcations implicitly add many such timing variables in a standard manner which 
makes the automata definitions and related proofs more readable. 

We use one simulation in this case study: in Chapter 4 a simulation shows that 
the composition of the buffer and controller of that chapter is an implementation 
of the controller of Chapter 3. Using the subtitutivity result of Theorem 2.6.2, the 
timeliness and safety properties follow because they are preserved by hybrid trace 
inclusion. 

This case study contains full proofs of the correctness of the various controllers. 
However, some of the proofs are only sketched, when similar formal proofs appear in 
other chapters. 

Evaluation 

The hybrid I/O automaton model and its related tools provide a framework in which 
a modest hybrid system can be described naturally and verified formally. Trajectories 
appear essential to a faithful treatment of physical systems. They permit differen- 
tial relationships between physical variables to be expressed directly. We also found 
shared variables useful. If the variables of a system are exposed then some prop- 
erties can be expressed as hybrid trace properties. This allows certain properties 
like the timeliness and safety properties to be cast as hybrid trace properties which 
in the timed I/O automaton model would necessarily have been properties of timed 
executions. 

The proofs in this case study are clear and scalable from the plain case to the 
feedback with delay case. We believe clarity and scalability are the result of our 
reliance on invariant assertions throughout. This technique enhances clarity because 
invariant assertions have a close relationship to intuitive, informal claims. The proofs 
of invariant assertions are usually by induction in a stylized manner which allows for 
easy navigation and checking. The assertional technique is scalable to more complex 
systems because often the invariant itself holds on the more complex system. Even if 
it does not, often the invariant of the simple system appears embedded in an invariant 



of the more complex system. For example, the invariant in Lemma 3.6.10 appears in 
clause 1 of the invariant in Lemma 5.6.5. When substitution like this occurs the proof 
of the original invariant can often be reused with minor modification. For example, 
compare the proofs of Lemmas 3.6.10 and 5.6.4. We believe this kind of reuse is 
characteristic of invariant assertion based methods. There remains the challenge of 
finding invariants that maximize reuse. 

We have a more guarded evaluation of simulations because of their more limited 
use in this case study. The simulation proof in Chapter 4 is clear and concise. How- 
ever, we acknowledge that its use is limited in two respects. First, it involves only the 
computer portion of the system. As a result, the components and the simulation itself 
could have been expressed using timed I/O automaton methods. Our contribution is 
in showing how this well understood method of proof for computer systems can be 
woven into the treatment of a hybrid system. 

Second, we acknowledge that the case study does not demonstrate that simulations 
scale from the delay case to the feedback with delay case. As mentioned in Chapter 6, 
no simulation is possible from a controller for the feedback with delay case to ZIG-ZAG, 
the example controller of Chapter 5. Because ZIG-ZAG always responds instantly to 
its sensor input, no controller with delayed responses can implement it. This begs 
the question of whether a simulation based proof in the feedback with delay case is 
possible given some other choice of controller for the feedback case. The answer is 
yes. However, we chose not to present such a controller because it would be overly 
complex without illustrating any new techniques or insights. The complexity of such 
a controller arises from its need to be highly non-deterministic both in when it sends 
multiple acceleration commands and which acceleration command it sends. This 
differs from the simple non-determinism of ONE-SHOT of Chapter 3 that merely varies 
the timing of two brake commands and not their content. 

Further Work 

This case study took shape during the early stages of the development of the HIOA 
model and does not exercise all the model's features. In particular, further case studies 
involving HIOA's could investigate more fully the use of shared variables. In this work 
we modeled the physical part of the system, the train, as a single automaton. We 
believe that the shared variables of HIOAs are the key to a more modular treatment 
of physical systems. Some modest progress in this direction appears in [15] where 
sensors and actuators are modeled as separate automata which share variables with 
the physical system. Nevertheless, we anticipate further progress in using this facet 
of the HIOA model. 

We look forward to further examination of the utility of simulation proofs for 
hybrid systems. An effort toward this begins in [14] but much remains to be done. 
We chose to avoid a highly abstract example controller in Chapter 5 because for 
this example the increased non-determinism would lead to complexity that would 



obscure the description. The utility of simulation proofs depends on the lucidity of 
more abstract specifications; we hope that our experience in this case study is the 
exception rather than the rule for hybrid systems. 

Much work remains for the M.I.T. Theory of Distributed Systems research group 
in our long-term project applying these techniques to automated transit systems. Cur- 
rent research involves further case studies in ground based transportation systems. 
We are modeling multi-vehicle maneuvers arising in the California PATH project 
[8, 9, 10]. The high-level and preliminary treatment of safety systems in [15] will 
be extended to examine the implementations of those systems in the Raytheon Per- 
sonal Rapid Transit project. We hope to develop a machine parsable language for 
hybrid system specifications and to develop tools for computer aided proof checking 
and verification. We are examining methods for integrating into our methods the 
techniques of relevant disciplines such as mechanical engineering and control theory. 
Our long term goal is to help design the industrial strength formal tools that will 
have an impact on the design and development of real transportation systems. 
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